Защо прекалено дългата парола отваря вратата
Проблемът се корени в начина, по който демонът sshd комуникира със стандартната C библиотека musl, когато OpenSSH работи без модула PAM (Pluggable Authentication Module). В Alpine стандартният пакет openssh-server е компилиран без PAM по подразбиране.
Когато даден акаунт няма парола, в системния файл /etc/shadow стойността за хеш съдържа само символа *. Тъй като този запис е твърде кратък за посоляване (salt), sshd заема солта от друг локален акаунт, който притежава реален хеш от типа $5$ (SHA-256) или $6$ (SHA-512). При обработката на въведената парола функцията crypt() на musl отказва да валидира низове над 256 байта и връща именно * като код за грешка. Този резултат съвпада напълно със съхранения в shadow файла *, поради което sshd приема влизането за успешно.
Кои системи са застрашени
Според бюлетина за сигурност на Alpine даден сървър е уязвим само ако са изпълнени едновременно следните четири условия:
използва се пакетът openssh-server (без PAM) или openssh-server-pam с настройка UsePAM no;
настройката PasswordAuthentication е зададена на yes (активна по подразбиране в OpenSSH);
на машината съществува акаунт със символ * в полето за парола (потребители с автентикация само с SSH ключ, служебни потребители през musl-nscd, или стандартният потребител alpine в облачните изображения);
съществува поне още един локален акаунт с паролен хеш от тип $5$ или $6$ (например създадена конзолна парола от администратор).
Системи, базирани на glibc (като Debian, Ubuntu, RHEL), инсталации с изключена автентикация с парола или акаунти, заключени с удивителен знак (!) в shadow файла, не са засегнати. Платформи като OpenWrt по подразбиране ползват Dropbear, който не съдържа този дефект.
Стъпки за защита и коригиране
За да защитите уязвимите машини, приложете следните конкретни мерки:
Обновете пакетите и рестартирайте sshd: Инсталирането на новия пакет в Alpine не рестартира работещата услуга автоматично. Изпълнете в терминала:
apk upgrade -U -a
rc-service sshd restart
Забранете автентикацията с парола: Ако не можете да приложите ъпдейта веднага, уверете се, че входът с публичен ключ работи, оставете текущата сесия отворена и задайте PasswordAuthentication no в конфигурационните файлове (в /etc/ssh/sshd_config или в директорията /etc/ssh/sshd_config.d/). Проверете синтаксиса с sshd -t и рестартирайте демона.
Как да проверите за евентуален пробив
Прегледайте системните логове във /var/log/messages за записи от вида Accepted password for за акаунти, които не би трябвало да имат парола (като alpine, root или потребители само с ключ). Ако откриете подобни индикатори, проверете използването на команди през doas/sudo, новосъздадени файлове и модификации в authorized_keys. При невъзможност да потвърдите легитимен достъп, експертите препоръчват машината да се третира като напълно компрометирана.
