Вразливість в OpenSSH і musl libc дає змогу увійти в обліковий запис без пароля за допомогою довгого рядка

Вразливість у взаємодії OpenSSH і бібліотеки musl libc дає змогу зловмиснику увійти в обліковий запис з вимкненим паролем, надіславши через SSH рядок довжиною від 257 до 1024 байтів. Насамперед уражені сервери Alpine Linux, де пакет openssh-server зібрано без підтримки PAM. Для експлуатації достатньо одного підключення — атака спрацьовує з першої спроби. Виправлення доступне в OpenSSH 10.6p2 та оновлених пакетах Alpine для гілок з 3.16 по 3.24. Адміністраторам уражених систем необхідно негайно оновити пакети та перезапустити sshd або вимкнути парольну автентифікацію.

Технічні деталі вразливості

Вразливості присвоєно ідентифікатор CVE-2026-123158 — згідно із записом у GitHub Advisory Database, її оцінено як високої критичності з попереднім балом CVSS 8.1. Варто враховувати, що цей запис має статус «unreviewed», ані OpenSSH, ані Alpine власної оцінки CVSS не публікували.

Згідно з бюлетенем безпеки Alpine Linux, для експлуатації необхідне одночасне виконання чотирьох умов:

• Сервер використовує пакет openssh-server без PAM (або openssh-server-pam з UsePAM no);
• Параметр PasswordAuthentication встановлено в yes (значення за замовчуванням в OpenSSH);
• У цільового облікового запису в полі пароля в /etc/shadow стоїть * — тобто пароль не задано (типово для облікових записів, які використовують лише SSH-ключі);
• У системі існує принаймні один інший обліковий запис із хешем пароля формату $5$ (SHA-256 crypt) або $6$ (SHA-512 crypt).

Варто відзначити розбіжність у джерелах щодо мінімальної довжини пароля, яка запускає вразливість: бюлетень Alpine вказує 257 байтів, тоді як запис у GitHub Advisory Database — 256 байтів. Верхня межа в обох випадках становить 1024 байти — це обмеження самого sshd.

Механізм вразливості

Проблема виникає на перетині трьох компонентів: обробки помилок у функції crypt() бібліотеки musl, механізму перевірки паролів у sshd без PAM і формату зберігання даних про облікові записи.

Коли sshd працює без PAM, він самостійно хешує введений пароль через crypt() і порівнює результат із збереженим значенням. Для облікових записів без пароля в полі хеша зберігається символ *. Оскільки цей рядок надто короткий, щоб витягти із нього сіль, sshd запозичує сіль в іншого облікового запису, що має справжній хеш. Цей механізм запозичення солі було запроваджено у 2016 році для усунення вразливості CVE-2016-6210, яка давала змогу визначати наявні імена користувачів за часом відповіді сервера.

Ключовий елемент — поведінка musl: під час обробки хешів $5$ і $6$ функція crypt() відмовляється працювати з паролями довшими за 256 байтів і повертає * як індикатор помилки. Це рішення було прийнято у 2012 році — замість повернення NULL у разі помилки musl почав повертати «хеш, що не збігається», оскільки багато програм не перевіряли NULL. Однак значення, що повертається, *, збігається з тим, що зберігається в /etc/shadow для облікових записів без пароля, і sshd вважає перевірку успішною.

Показово, що розробники OpenSSH і musl розходяться в оцінці першопричини. Згідно з примітками до випуску OpenSSH 10.6p2, команда OpenSSH вважає корінь проблеми зовнішнім щодо sshd, хоча експлуатацію можна запобігти на його боці. Розробник musl Річ Фелкер, своєю чергою, вказує, що проблема — в тому, як програма, що викликає, обробляє значення, яке повертає crypt().

Масштаб впливу

Уражені всі версії Alpine Linux з 3.16 по 3.24 і гілка edge за наявності описаної конфігурації. Системи на базі glibc, а також будь-які конфігурації з увімкненим PAM цій вразливості не піддаються.

Особливої уваги заслуговують хмарні образи Alpine на базі tiny-cloud версій з 3.18.11 по 3.24.3. У них присутній обліковий запис alpine з полем пароля * і правом виконувати команди через doas без пароля. Такі образи безпечні під час першого запуску, але стають уразливими, щойно в системі з’являється принаймні один хеш формату $6$ — наприклад, після того як адміністратор задасть пароль для консольного доступу. У такому разі зловмисник може увійти як alpine і отримати права root через doas.

Обліковий запис root за замовчуванням захищений налаштуванням PermitRootLogin prohibit-password, однак це не допомагає, якщо скомпрометований обліковий запис має змогу підвищувати привілеї.

Що стосується інших систем на musl — дослідник Озгюн Кюльтекін із компанії Wakefield, який виявив вразливість, згадує OpenWrt, Buildroot і Yocto як платформи, що потребують перевірки. Однак практичний радіус ураження вужчий, ніж може здатися: типовий OpenWrt використовує Dropbear як SSH-сервер, як це випливає з документації OpenWrt, і Dropbear цій вразливості не піддається. Проблема актуальна для OpenWrt лише у разі ручного встановлення OpenSSH адміністратором.

Публічний PoC для відтворення вразливості вже доступний, однак повідомлень про експлуатацію в реальних атаках на момент публікації не надходило.

Рекомендації щодо усунення

Згідно з бюлетенем Alpine, щоб усунути вразливість, необхідно:

1. Оновити пакети: apk upgrade -U -a
2. Перезапустити sshd: rc-service sshd restart — оновлення пакета не перезапускає запущений процес sshd автоматично.

Виправлені пакети включено до проміжних релізів Alpine 3.21.10, 3.22.8, 3.23.8 і 3.24.4. Гілки 3.16–3.20, які вже вийшли з регулярної підтримки, також отримали виправлення.

За самостійної збірки OpenSSH слід оновитися до версії 10.6p2, що містить тимчасове рішення — sshd тепер відхиляє збіг, якщо збережене поле пароля коротше чотирьох символів.

Якщо негайне оновлення неможливе, необхідно вимкнути парольну автентифікацію:

• Переконатися, що вхід за SSH-ключем працює, і не закривати поточну сесію до перевірки нового підключення;
• Встановити PasswordAuthentication no у конфігурації sshd;
• Перевірити конфігурацію: sshd -t;
• Перезапустити sshd;
• Переконатися в результаті: sshd -T | grep -i passwordauthentication має вивести passwordauthentication no.

Для виявлення можливої компрометації бюлетень Alpine рекомендує перевірити /var/log/messages на наявність записів Accepted password for для облікових записів без пароля — таких як alpine, root або облікові записи, що використовують лише ключі. На потенційно скомпрометованих машинах слід також перевірити використання doas, нещодавно створених користувачів, файли та авторизовані ключі. Як зазначено в бюлетені: «Якщо ви не можете виключити факт входу — вважайте машину скомпрометованою».

Адміністраторам Alpine Linux з увімкненим SSH-доступом слід оновити пакети та перезапустити sshd насамперед на хмарних екземплярах tiny-cloud версій 3.18.11–3.24.3, де поєднання вразливості з правами doas створює прямий шлях до отримання root. На всіх інших уражених системах пріоритет оновлення визначається наявністю чотирьох описаних умов — якщо хоча б одна з них не виконується, система не піддається цій атаці.