OpenSSH: уязвимость в GSSAPI-патчах дистрибутивов Linux
Что случилось
В OpenSSH выявлена уязвимость, связанная с обработкой ошибок в механизме GSSAPI-аутентификации. Проблема кроется в патчах, которые дистрибутивы Linux накладывают поверх upstream-версии OpenSSH — сам проект OpenSSH официально не затронут.
При получении неожиданного типа сообщения во время GSSAPI-key exchange сервер вызывает sshpkt_disconnect(), которая не прерывает выполнение процесса. Переменные соединения остаются неинициализированными, и последующий код обращается к случайным областям памяти. Это открывает возможность для непредсказуемого поведения: от сбоя службы до потенциальной утечки данных или выполнения произвольного кода — в зависимости от настроек компилятора и флагов защиты.
Кого касается
Уязвимость актуальна для:
- Серверов с включённой GSSAPI-аутентификацией в OpenSSH
- Систем на базе дистрибутивов, применяющих собственные GSSAPI-патчи (RHEL, CentOS, Debian, Ubuntu и производные)
- Инсталляций, где SSH-сервер доступен из недоверенных сетей
Если GSSAPI отключён в sshd_config (по умолчанию часто так и есть), эксплуатация невозможна.
Что делать
1. Проверьте версию и источник пакета
Определите, откуда установлен OpenSSH:
ssh -V
Для RPM-систем:
rpm -qi openssh-server | grep Source
Для DEB-систем:
apt-cache policy openssh-server
2. Обновите пакет
Установите исправленную версию из репозитория вашего дистрибутива:
# RHEL/CentOS/Rocky/Alma sudo dnf update openssh-server # Debian/Ubuntu sudo apt update && sudo apt upgrade openssh-server
Перезапустите службу:
sudo systemctl restart sshd
3. Временное отключение GSSAPI (обходной путь)
Если обновление невозможно немедленно, отключите уязвимый механизм в /etc/ssh/sshd_config:
GSSAPIAuthentication no GSSAPICleanupCredentials no
Перезапустите sshd и убедитесь, что подключения работают.
4. Проверьте флаги компиляции
Узнайте у провайдера VPS или в документации дистрибутива, включены ли hardening-флаги (ASLR, stack canaries, FORTIFY_SOURCE). Чем агрессивнее защита, тем сложнее эксплуатация.