Qualys: критическая уязвимость CVE-2024-6387 (regreSSHion) в OpenSSH

В начале июля 2024 команда Qualys (Threat Research Unit) сообщила о критической уязвимости в OpenSSH: CVE-2024-6387, публично известной как regreSSHion. Это race condition в обработчике сигнала в sshd: при определённых условиях на системах с glibc возможна удалённая неаутентифицированная эксплуатация с выполнением кода от root. Ниже – суть, версии, риски и что делать на практике.

OpenSSH в двух словах

OpenSSH – стандартный набор для удалённого доступа: sshd на сервере, клиент ssh, scp/sftp. На большинстве Linux-серверов порт 22 (или альтернативный) слушает именно OpenSSH. Любая RCE в sshd до логина – событие максимального приоритета для патч-менеджмента.

CVE-2024-6387 (regreSSHion)

Суть

Уязвимость связана с обработкой таймаута LoginGraceTime: при срабатывании сигнала вызываются не async-signal-safe функции (в т.ч. работа с syslog и кучей в glibc). Злоумышленник, удерживая множество незавершённых соединений, может попасть в гонку и, в успешном сценарии Qualys, добиться выполнения кода с правами процесса sshd (часто root). Это не «магический один пакет», а эксплуатация race condition: в лабораторных условиях Qualys показывала длительные серии попыток; в реальном интернете сложность выше, но риск для открытых sshd остаётся высоким.

Затронутые версии

По описанию Qualys и CVE:

• OpenSSH с 8.5p1 включительно (регрессия относительно старого CVE-2006-5051) до 9.7p1 на платформах с glibc;
• исправление вошло в OpenSSH 9.8p1 и в бэкпорты дистрибутивов;
• старые ветки до 8.5 и сборки без glibc (часть *BSD / musl) в исходном анализе выглядели иначе – опирайтесь на advisory своего вендора.

Проверка версии на хосте:

ssh -V
# или
sshd -V 2>&1

Последствия успешной атаки

• полный контроль над сервером (root);
• кража ключей, токенов, данных БД;
• закрепление (бэкдоры, новые пользователи, cron);
• латеральное движение по сети.

Даже если надёжный публичный эксплойт «в один клик» появился не сразу, массовое сканирование 22/tcp и попытки эксплуатации после disclosure – нормальная картина. Открытый sshd без патча – плохая ставка.

Что делать

1. Обновить OpenSSH

Приоритет номер один – пакеты дистрибутива с фиксом (или 9.8p1+):

# Debian / Ubuntu (пример)
sudo apt update
sudo apt install --only-upgrade openssh-server
ssh -V
sudo systemctl restart ssh
# на части систем сервис называется sshd

Сверьте changelog и advisory: Ubuntu, Debian, RHEL, Alma, Rocky публиковали отдельные CVE-пакеты. После обновления перезапуск sshd обязателен.

2. Временные смягчения (если патч ещё не доступен)

• ограничить доступ к SSH по IP (firewall, security group; fail2ban/crowdsec не заменяют патч, но режут шум);
• не торчать 22/tcp в весь интернет без VPN или bastion;
• как workaround из обсуждений вокруг CVE: LoginGraceTime 0 убирает срабатывание таймера, но повышает риск исчерпания слотов соединений (DoS) – только осознанно и кратко;
• ключи вместо паролей, отключение root-login по паролю – хорошая гигиена, но не лечат pre-auth regreSSHion.

3. Мониторинг

Смотрите всплески незавершённых SSH-сессий, аномалии в auth.log/journal, IDS-сигнатуры под CVE-2024-6387. После патча имеет смысл сверка целостности и обзор «лишних» ключей в authorized_keys.

Итог

CVE-2024-6387 – редкий по критичности класс: pre-auth RCE в широко развёрнутом sshd на glibc. План простой: обновить OpenSSH из доверенных репозиториев, перезапустить сервис, сузить экспозицию SSH. Детали и PoC-методология – в материалах Qualys; патчи – у OpenBSD/OpenSSH и мейнтейнеров дистрибутивов.

Источники и ссылки