SSHole или как журналисты обнаружили критическую уязвимость в OpenSSH, забыв разобраться, что именно уязвимо

В социальных сетях началась очередная эпидемия сообщений об ужасной критической уязвимости OpenSSH, позволяющей получить доступ к Linux-серверу без пароля.

Есть несколько маленьких нюансов, которые почему-то теряются в процессе перепечатывания страшных заголовков.

1. Проблема связана с некорректной обработкой результата crypt() в musl libc. На системах с glibc этой проблемы нет.

2. Уязвимость касается OpenSSH. Например, штатный SSH-сервер OpenWRT — Dropbear. Он не использует уязвимый механизм. Но зачем разбираться в деталях, если можно написать страшный пост?

3. Основная область распространения musl в серверной инфраструктуре — Alpine Linux, который чаще всего встречается в качестве основы контейнерных образов. В большинстве таких контейнеров SSH-сервера вообще нет. Правда, существуют и полноценные серверные установки Alpine, которые действительно требуют внимания.

4. Использование PAM меняет условия эксплуатации. В штатной конфигурации большинства серверных дистрибутивов с glibc проблема вообще отсутствует.

Итого: существует серьёзная уязвимость конкретной комбинации OpenSSH, musl и настроек аутентификации. Её необходимо исправлять там, где она действительно применима.

Но превращать это в «критическую уязвимость OpenSSH, угрожающую всем Linux-серверам» — примерно то же самое, что объявлять уязвимостью всех автомобилей ошибку в тормозной системе конкретной модели с конкретной модификацией ABS.

Иногда перед публикацией очередного апокалиптического поста полезно прочитать не только заголовок CVE, но и техническое описание уязвимости.

Хотя, судя по некоторым публикациям, это уже слишком радикальное требование к современной информационной безопасности.