В GnuTLS устранили двухлетнюю уязвимость

В GnuTLS устранили двухлетнюю уязвимость

В GnuTLS устранили двухлетнюю уязвимость

На прошлой неделе разработчики устранили опасную уязвимость в GnuTLS, библиотеке с открытым исходным кодом для имплементации протокола TLS. Самое удивительное, что эта брешь существовала в коде почти два года, следовательно, сессии TLS 1.3 были уязвимы для атаки.

Проблема безопасности, описанная специалистами на площадке GitHub, позволяла серверам GnuTLS использовать билеты сессии, которые были выпущены ещё при прошлом соединении. При этом необязательно было задействовать функцию, которая генерирует закрытые ключи — gnutls_session_ticket_key_generate().

Проще говоря, потенциальный злоумышленник мог использовать данную уязвимость для обхода процесса аутентификации TLS 1.3. Баг впервые появился в GnuTLS 3.6.4 (релиз состоялся 24 сентября 2018 года), а устранили его в GnuTLS 3.6.14 (3 июня 2020 года).

Эндрю Айер, основатель SSLMate, в Twitter подробно расписал своё видение этого бага. По словам Айера, уязвимость создала сложная система ротации ключей.

Впрочем, Айер и раньше высказывался негативно по поводу GnuTLS, называя библиотеку «клоунской» имплементацией TLS.

HTTP/2 Bomb: одна машина может положить сервер за считаные секунды

Эпоха ботнетов для организации мощных DDoS-атак получила ещё одного игрока. Исследователи рассказали о новой технике отказа в обслуживании под названием HTTP/2 Bomb, которая позволяет буквально положить крупный веб-сервер силами всего одной машины.

Самое неприятное — атака работает против стандартных конфигураций популярных серверов, включая NGINX, Apache HTTP Server, Microsoft IIS, Envoy и Cloudflare Pingora.

Метод обнаружили специалисты компании Calif при помощи ИИ-агента Codex от OpenAI. Фактически HTTP/2 Bomb — это комбинация двух известных приёмов: усиления через механизм сжатия заголовков HPACK и удержания ресурсов по схеме Slowloris с использованием особенностей управления потоком в HTTP/2.

На практике злоумышленник заставляет сервер выделять огромные объёмы памяти, после чего блокирует её освобождение. В результате память продолжает расходоваться, а сервер постепенно перестаёт отвечать на запросы.

По данным исследователей, обычный домашний компьютер с каналом 100 Мбит/с способен вывести из строя уязвимый сервер за считаные секунды. Например, Apache httpd и Envoy можно заставить выделить и удерживать 32 Гбайт оперативной памяти примерно за 20 секунд.

Во время испытаний результаты оказались впечатляющими:

  • Envoy 1.37.2 — 32 Гбайт RAM за 10 секунд;
  • Apache httpd 2.4.67 — 32 Гбайт за 18 секунд;
  • NGINX 1.29.7 — 32 Гбайт за 45 секунд;
  • Microsoft IIS на Windows Server 2025 — 64 Гбайт за 45 секунд.

Особую пикантность ситуации добавляет тот факт, что опубликованы уже не только технические детали, но и готовые эксплойты.

Исправления уже доступны для NGINX 1.29.8 и Apache mod_http2 2.0.41. Для Apache проблема зарегистрирована под идентификатором CVE-2026-49975. А вот пользователям IIS, Envoy и Pingora пока остаётся ждать патчей либо временно отключать HTTP/2 и использовать прокси-серверы или файрволы с жёсткими ограничениями на количество заголовков.

RSS: Новости на портале Anti-Malware.ru