Вразливість OpenSSH «sshole»: як довгий пароль відкриває доступ без пароля на Alpine Linux

Що сталося

5 листопада 2026 року проєкт OpenSSH випустив позачергове оновлення 10.6p2, яке закриває уразливість обходу автентифікації — CVE-2026-123158, якій дослідники дали назву «sshole». Проблему виявив і повідомив 4 листопада дослідник Özgün Kültekin із компанії Wakefield. Вона стосується систем на musl libc без PAM — насамперед Alpine Linux, дистрибутива, який через компактність став фактичним стандартом для Docker-контейнерів і вбудованих систем.

Суть лякає своєю простотою: атакуючий може увійти по SSH в обліковий запис, для якого пароль взагалі не встановлено, просто надіславши дуже довгий пароль — від 257 до 1024 байтів. Жодного зламу криптографії тут немає: причина — в особливості роботи бібліотеки musl libc, яка не змінювалася ще з 2012 року. Сам проєкт OpenSSH оцінив уразливість як критичну, а MITRE присвоїв їй бал CVSS 3.1 — 8.1 (High) з вектором AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H: атака йде по мережі, не потребує попередніх прав і призводить до повної компрометації.

Хто під загрозою

Уразливість стосується не всіх систем, але коло уражених ширше, ніж здається. Ви вразливі, якщо одночасно виконуються умови:

• ви запускаєте openssh-server з Alpine Linux (зібраний без PAM) або openssh-server-pam з UsePAM no;
• у sshd увімкнена парольна автентифікація (PasswordAuthentication yes — значення за замовчуванням);
• на машині є акаунт, у якого поле пароля в shadow-файлі дорівнює * — це норма для «ключових» акаунтів, службових обліковок і користувачів із каталогових сервісів через musl-nscd (nslcd, winbind, sssd);
• на машині є хоча б один інший акаунт із реальним хешем $5$ або $6$.

Один користувач із паролем робить досяжними всі акаунти без пароля. Особливість у тому, що root у базових образах Alpine починаючи з версії 3.16 теж має поле *, — але за замовчуванням PermitRootLogin prohibit-password захищає його. Справжній ризик — непрямий доступ до root: в офіційних хмарних образах AWS і Azure (tiny-cloud версій 3.18.11–3.24.3) користувач alpine має * і passwordless doas, тобто вхід під ним фактично означає root. Дистрибутиви на glibc — Debian, Ubuntu, RHEL, Fedora — а також системи з PAM, Dropbear і OpenBSD цієї проблеми не мають.

Як працює вразливість: один символ із двома значеннями

Щоб зрозуміти механізм, розберімо, як sshd перевіряє пароль без PAM. Демон бере введений пароль, обчислює його хеш через функцію crypt() і порівнює результат із рядком у shadow-файлі. Якщо рядки збігаються — вхід дозволено. Проблема в тому, що значення * у цьому ланцюжку має два різні сенси.

З 2012 року crypt() у musl, коли не може обробити вхід, повертає не NULL, як інші бібліотеки, а рядок *. Водночас реалізації SHA-256 і SHA-512 у musl відмовляються хешувати паролі довші за 256 байтів. Водночас з 2016 року sshd (щоб закрити іншу вразливість CVE-2016-6210 — витік імен користувачів за часом відповіді) навчився «позичати» сіль з іншого акаунта, якщо в цільового акаунта поле пароля закоротке. Ланцюжок атаки виглядає так:

1. Атакуючий надсилає пароль довжиною від 257 до 1024 байтів.
2. crypt() відмовляється хешувати такий довгий рядок і повертає *.
3. sshd порівнює цей * із полем пароля цільового акаунта, де стоїть саме *.
4. Рядки збігаються — автентифікацію пройдено.

Інакше кажучи, це класична колізія «помилка vs. службове значення»: повернутий індикатор помилки * збігся зі службовим *, який позначає «пароля немає». OpenSSH 10.6p2 закриває шлях на рівні sshd, відкидаючи збережені хеші коротші за чотири символи.

Є й екзотичніший різновид: якщо перший знайдений sshd хеш — bcrypt ($2b$), то sshd копіює лише префікс $2b$10$ без солі, musl вважає такий рядок невалідним і повертає * для будь-якого пароля — тоді підходить навіть короткий. На Alpine bcrypt рідкісний, але трапляється, коли хеші генеруються деінде й копіюються в shadow-файл. Ще один нюанс, який варто знати сканерам: успішний вхід потребує двох спроб пароля в межах одного TCP-з'єднання — перша спроба завжди провалюється через перезапис внутрішнього буфера, друга проходить. Тому сканер, який шле по одному паролю на з'єднання, помилково позначає вразливі хости як чисті.

Перші атаки в дикій природі

Якщо спочатку здавалося, що час на оновлення є, то вже наступного дня це спростували. 6 листопада засновник threat-intelligence компанії Previdian Раян Дьюгерст повідомив, що сенсори фірми зафіксували реальні атаки, і щонайменше одна з них завершилася успіхом.

«Наша перша зафіксована спроба надійшла менш ніж за дев'ять годин після публікації CVE, і ми підтвердили успішний доступ до root на хоніпоті Previdian, де працювали справжні Alpine Linux і OpenSSH», — розповів він Help Net Security. Атакуюча адреса 89.116.89[.]18 (японський хостинг) використовувала негабаритні паролі й виконувала розвідувальні команди id, uname і hostname через неінтерактивні SSH-сесії. Загалом Previdian нарахував вісім спроб — усі з однієї адреси й усі спіймані одним сенсором.

Компанія внесла CVE-2026-123158 до власного списку відомих експлуатованих уразливостей, хоча CISA поки не додала її до свого каталогу KEV. На GitHub уже з'явилися proof-of-concept експлойти, але Previdian застерігає, що вони неперевірені й можуть містити шкідливий код. Розробник OpenSSH Дам'єн Міллер у Mastodon закликав негайно діяти: «Припиніть читати і вимкніть PasswordAuthentication або SSH для цих систем НЕГАЙНО».

Чому це серйозно: контейнери, роутери та «docker images you've pulled»

На перший погляд тема може здатися вузькою — «лише Alpine Linux». Але Alpine — базовий образ для величезної кількості контейнерів у світі: від мікросервісів до CI/CD-ранерів. Якщо в контейнері, піднятому з Alpine, запущено sshd із парольною автентифікацією, він вразливий. Сам Кюльтекін перелічує серед вартих перевірки системи на musl: OpenWrt, Buildroot і Yocto, а також — дослівно — «купу Docker-образів, які ви собі стягнули».

Окремий випадок — роутери. У OpenWrt пакунок openssh-server зібраний на musl без PAM і використовує апстрімну конфігурацію з PasswordAuthentication yes і AllowTcpForwarding yes. Після того як у root з'являється пароль (а на майже кожному налаштованому роутері він є), службові акаунти daemon, network і nobody (з полем * і шелом /bin/false) можна обійти й використати як тунель у локальну мережу. Важливо: за замовчуванням OpenWrt використовує Dropbear, який не вразливий, — проблема виникає, лише якщо адміністратор сам установив OpenSSH.

Як перевірити, чи ви вразливі

Найнадійніший спосіб — перевірити фактичну конфігурацію, а не покладатися на версію пакунка. По-перше, подивіться, як працює ваш sshd:

  sshd -T | grep -i -E 'passwordauthentication|usepam'

Система не вразлива, якщо парольна автентифікація вимкнена або увімкнений PAM. По-друге, перевірте наявність акаунтів-«цілей» і реального хеша:

  awk -F: '$2=="*"{print $1}' /etc/shadow
  awk -F: '$2 ~ /^\$[56]\$/{print $1}' /etc/shadow

Якщо перша команда виводить акаунти, відмінні від root (або root, але з PermitRootLogin yes), а друга — хоча б один акаунт, хост експлуатується до встановлення патча. Окремо зверніть увагу на Alpine: у виправлених пакунках зберігаються старі номери версій (наприклад, 10.3_p1, а не 10.6), тому сканери, які порівнюють версію лише з порогом 10.6p2, помилково позначають пропатчені хости як вразливі. Звіряйтеся з версіями пакунків Alpine для вашої гілки.

Як захиститися та виявити злам

Найголовніше — оновитися і, що критично, перезапустити демон sshd. Оновлення пакунка саме по собі не замінює запущений процес: старий код працює, доки sshd не перезапустять.

1. Оновіть пакунки: apk upgrade -U -a.
2. Перезапустіть службу: rc-service sshd restart.
3. Якщо оновитися поки неможливо — вимкніть парольну автентифікацію (PasswordAuthentication no в sshd_config) і перезапустіть sshd. Це надійний тимчасовий захист, адже атака йде саме через парольний шлях. Спершу переконайтеся, що вхід за ключами працює.

Виправлені версії openssh для гілок Alpine: edge — 10.6_p2-r0, 3.24 — 10.3_p1-r2, 3.23 — 10.2_p1-r1, 3.22 — 10.0_p1-r11, 3.21 — 9.9_p2-r1, 3.20 — 9.7_p1-r6, 3.19 — 9.6_p1-r3, 3.18 — 9.3_p2-r4, 3.17 — 9.1_p1-r7, 3.16 — 9.0_p1-r6. Для інших систем — оновіться до OpenSSH 10.6p2 або новішої. Контейнери слід перезбирати на основі виправлених базових образів, а не просто перезапускати наявні.

Якщо вимкнути парольну автентифікацію з якоїсь причини неможливо, але захиститися треба вже, є ще один тимчасовий прийом: замінити значення * у shadow-файлі цільового акаунта на довший заповнювач, який не починається з ! (наприклад, *NP*). Тоді поле перестає бути однобайтовим, sshd більше не «позичає» сіль, а musl повертає звичайний рядок, який ніколи не збігається, — вхід за ключем при цьому продовжує працювати. Зробити це можна, наприклад, командою echo 'alpine:*NP*' | chpasswd -e, але лише як доповнення до PasswordAuthentication no та як місток до встановлення патча.

Для виявлення вже здійсненого зламу SOCRadar радить шукати в /var/log/messages (і архівах) записи Accepted password for на імена акаунтів без пароля — alpine, root, ключові користувачі, — а також переглядати історію використання doas, нещодавно створених користувачів і файли authorized_keys. Якщо підозрілий вхід не можна виключити, машину слід вважати скомпрометованою.

Швидкість реагування в епоху ШІ

Історія «sshole» показова й тим, як її знайшли. Кюльтекін зібрав sshd у всіх можливих комбінаціях і прогнав через нього близько 17 600 нестандартних спроб входу — і, за власним зізнанням, не сам: «в мене були рої агентів. Багато. Не будемо про це». Вразливою виявилася лише збірка на musl без PAM.

Це частина ширшого тренду. Мейнтейнери OpenSSH тепер уникають довгих ембарго, бо AI-інструменти повторно відкривають уже відомі їм баги — іноді за лічені години. А з боку атакуючих, за словами Дьюгерста, зловмисники стають швидшими саме завдяки ШІ: «Ця вразливість була тривіальною в експлуатації, що значно скоротило часове вікно». Змагання між патчем і експлойтом тепер вимірюється годинами, а не тижнями.

Висновок

CVE-2026-123158 — нагадування, що критичні вразливості можуть роками ховатися в «низькому рівні» — у взаємодії між системною бібліотекою та демоном, — поки хтось не з'єднає крапки. Тут немає зламу криптографії і немає складного експлойта: достатньо довгого рядка замість пароля. Але саме через простоту й масовість Alpine в контейнерній інфраструктурі атака стартувала менш ніж за дев'ять годин після публікації. Тож реагуйте негайно: оновіть OpenSSH, перезапустіть sshd, а якщо це неможливо — вимкніть парольну автентифікацію й перейдіть на ключі.

Якщо ви не впевнені, чи ваші облікові дані не були скомпрометовані в попередніх витоках, перевірте їх через перевірку витоків, а про те, як будувати кар'єру і навички в кібербезпеці, читайте в матеріалі про навчання кібербезпеці.