- 27,252
- 46
- 8 Ноя 2022
Новая атака кладёт Apache, nginx и IIS мгновенно — и для этого не нужен ботнет, только ноутбук.
Исследователи Calif нашли уязвимость HTTP/2 Bomb, которая позволяет удалённо перегрузить память популярных веб-серверов и быстро довести сервис до отказа. Проблема затрагивает конфигурации HTTP/2 по умолчанию в nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora. Для атаки не требуется крупный ботнет: по оценке исследователей, обычный домашний компьютер с каналом 100 Мбит/с способен сделать уязвимый сервер недоступным за несколько секунд.
HTTP/2 Bomb объединяет две известные техники: компрессионную бомбу и удержание соединения в стиле Slowloris. По отдельности оба приёма давно знакомы разработчикам серверов и специалистам по защите инфраструктуры. Новая схема опасна сочетанием: сначала сервер заставляют выделять память на обработку множества заголовков, а затем клиент удерживает соединение открытым и не даёт освободить ресурсы.
Компрессионная часть атаки нацелена на HPACK, алгоритм сжатия заголовков в HTTP/2. Заголовки передают служебные данные запроса и ответа: адрес, Cookie, тип содержимого, параметры кеширования и другие поля. Без сжатия метаданные занимали бы слишком много места, особенно при большом числе однотипных запросов. HPACK решает эту задачу через динамическую таблицу: сторона соединения один раз добавляет заголовок, а дальше может ссылаться на него коротким индексом, иногда всего одним байтом.
При нормальной работе механизм экономит трафик и снижает накладные расходы. В HTTP/2 Bomb экономия превращается в усилитель нагрузки. Атакующий заранее помещает заголовок в динамическую таблицу, а потом отправляет тысячи коротких индексных ссылок. Один байт в сетевом пакете заставляет сервер создать полноценную структуру заголовка в памяти. Повтор операции тысячи раз за один запрос создаёт резкий разрыв между затратами атакующего и расходом памяти на стороне сервера.
Часть атаки, похожая на Slowloris, использует управление потоком в HTTP/2. Протокол позволяет получателю объявлять размер окна, то есть сообщать отправителю, сколько байтов можно передать дальше. В HTTP/2 Bomb клиент задаёт для ответа сервера нулевое окно управления потоком. Сервер не может завершить передачу ответа, поэтому не закрывает поток и не освобождает память, уже выделенную под обработку заголовков.
Чтобы соединение не истекло по таймауту, атакующий периодически отправляет крошечные кадры WINDOW_UPDATE. Сервер видит активность и продолжает держать поток живым, но фактически не может нормально завершить обработку запроса. В результате память остаётся закреплённой за зависшим потоком столько времени, сколько позволяют таймауты и настройки конкретной реализации HTTP/2.
Исследователи подчёркивают, что отдельные элементы атаки не выглядят новыми. HPACK Bomb обсуждали ещё в 2016 году в контексте CVE-2016-6581 . В Apache httpd ранее находили похожие проблемы с истощением памяти в HTTP/2, включая CVE-2025-53020 . Похожие DoS-уязвимости возникали через специально сформированные кадры CONTINUATION и истощение рабочих потоков в соединениях HTTP/2. HTTP/2 Bomb отличается источником усиления нагрузки.
Классическая компрессионная бомба обычно помещает в таблицу крупное значение и многократно ссылается на него. Серверы научились ограничивать общий размер распакованных заголовков, поэтому простое увеличение значения чаще упирается в лимит. В новой схеме заголовок почти пустой. Нагрузка появляется не из-за размера распакованных данных, а из-за служебных структур, которые сервер создаёт вокруг каждой записи. Лимит на размер декодированных заголовков не срабатывает, потому что декодировать почти нечего.
Для серверов, которые ограничивают количество полей заголовков, исследователи нашли обход через Cookie. Спецификация HTTP/2 допускает разделение заголовка Cookie на несколько отдельных полей, чтобы повысить эффективность сжатия. Apache httpd и Envoy в проверенной конфигурации не учитывали фрагменты Cookie как обычные поля при подсчёте лимита. Дальнейший эффект зависел от того, как сервер заново собирает Cookie перед передачей запроса приложению.
Envoy добавляет каждый фрагмент Cookie в буфер. При крупном значении Cookie, на которое ссылаются десятки тысяч раз, логическое усиление достигает примерно 3600:1, а измеренное потребление памяти с учётом накладных расходов поднимается выше. В демонстрации Calif для Envoy 1.37.2 коэффициент усиления составил около 5700:1, а потребление памяти выросло примерно до 32 ГБ за 10 секунд.
Apache httpd ведёт себя иначе и пересобирает объединённую строку Cookie при добавлении каждого фрагмента. Старые копии остаются в памяти до очистки потока, поэтому даже пустой Cookie может давать усиление около 4000:1. В демонстрации Apache httpd 2.4.67 занял около 32 ГБ памяти примерно за 18 секунд.
nginx и Microsoft IIS показали меньший коэффициент усиления, но проблема всё равно приводит к отказу в обслуживании. В тестах Calif nginx 1.29.7 давал около 70:1 и набирал примерно 32 ГБ памяти за 45 секунд. Microsoft IIS на Windows Server 2025 показал около 68:1 и около 64 ГБ памяти за тот же промежуток времени. Для атаки на реальный сервер злоумышленнику не обязательно доводить процесс до аварийного завершения. Более выгодная тактика - удерживать нагрузку чуть ниже порога завершения процесса, загнать систему в swap и резко замедлить обработку остальных запросов.
HTTP/2 Bomb обнаружил OpenAI Codex при анализе серверных кодовых баз. По описанию Calif, модель связала две давно известные идеи в рабочую цепочку и помогла построить комбинированный вариант атаки. Исследователи отдельно отмечают, что после публикации исправляющих коммитов путь от diff-файла до работоспособного эксплойта становится очень коротким: современные ИИ-инструменты уже способны восстановить логику атаки по изменениям в коде.
Calif раскрыла проблему nginx в апреле. Разработчики nginx добавили директиву max_headers и выпустили версию 1.29.8 на следующий день. Директива по умолчанию ограничивает число заголовков значением 1000. Если быстро обновить сервер нельзя, исследователи советуют отключить HTTP/2 директивой http2 off;.
Apache получил уведомление 27 мая. Исправление попало в mod_http2 v2.0.41: фрагменты Cookie теперь учитываются при проверке LimitRequestFields. Патч доступен в отдельном выпуске mod_http2 и в основной ветке httpd, но на момент публикации Calif ещё не входил в стабильный выпуск Apache httpd 2.4.x. При невозможности обновления временная защита сводится к отключению HTTP/2 через Protocols http/1.1.
Снижение LimitRequestFieldSize в Apache может уменьшить ущерб в пределах одного потока, потому что ограничивает размер объединённого Cookie и число его фрагментов. Такой шаг не закрывает проблему полностью: атакующий может распределить нагрузку по нескольким потокам и соединениям. Уменьшение LimitRequestFields против этой схемы не помогает, если сервер не считает повторяющиеся фрагменты Cookie как отдельные поля.
Для Microsoft IIS, Envoy и Cloudflare Pingora на момент публикации Calif готовых исправлений не было. В таких конфигурациях исследователи советуют отключать HTTP/2 там, где это допустимо, или ставить перед уязвимым сервером компонент, который жёстко ограничивает количество заголовков в запросе. Защита должна учитывать общий размер декодированных заголовков и число полей, включая отдельные фрагменты Cookie.
Общее правило для точек терминации HTTP/2 звучит просто: лимит размера заголовков и лимит количества заголовков решают разные задачи. Серверу нужны оба ограничения. Дополнительно инфраструктура должна ограничивать срок жизни зависшего потока, даже если клиент периодически отправляет WINDOW_UPDATE и формально поддерживает активность соединения.
Если обновление и отключение HTTP/2 невозможны, Calif советует ограничивать память рабочих процессов через cgroups, ulimit -v или лимиты контейнеров. Такой подход не устраняет уязвимость, но меняет режим отказа. Лучше быстро завершить один перегруженный worker и запустить новый процесс, чем позволить атакующему удерживать почти всю память сервера и тормозить остальные запросы.
Главный просчёт связан не с одной реализацией, а с тем, как спецификация описывает риск истощения памяти. HPACK учитывает опасность усиления через динамическую таблицу и предлагает ограничивать её размер через SETTINGS_HEADER_TABLE_SIZE. HTTP/2 Bomb показывает другой путь: даже умеренный коэффициент усиления становится опасным, если клиент почти бесплатно держит соединение открытым и закрепляет каждый выделенный байт памяти за незавершённым потоком.
Исследователи Calif нашли уязвимость HTTP/2 Bomb, которая позволяет удалённо перегрузить память популярных веб-серверов и быстро довести сервис до отказа. Проблема затрагивает конфигурации HTTP/2 по умолчанию в nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora. Для атаки не требуется крупный ботнет: по оценке исследователей, обычный домашний компьютер с каналом 100 Мбит/с способен сделать уязвимый сервер недоступным за несколько секунд.
HTTP/2 Bomb объединяет две известные техники: компрессионную бомбу и удержание соединения в стиле Slowloris. По отдельности оба приёма давно знакомы разработчикам серверов и специалистам по защите инфраструктуры. Новая схема опасна сочетанием: сначала сервер заставляют выделять память на обработку множества заголовков, а затем клиент удерживает соединение открытым и не даёт освободить ресурсы.
Компрессионная часть атаки нацелена на HPACK, алгоритм сжатия заголовков в HTTP/2. Заголовки передают служебные данные запроса и ответа: адрес, Cookie, тип содержимого, параметры кеширования и другие поля. Без сжатия метаданные занимали бы слишком много места, особенно при большом числе однотипных запросов. HPACK решает эту задачу через динамическую таблицу: сторона соединения один раз добавляет заголовок, а дальше может ссылаться на него коротким индексом, иногда всего одним байтом.
При нормальной работе механизм экономит трафик и снижает накладные расходы. В HTTP/2 Bomb экономия превращается в усилитель нагрузки. Атакующий заранее помещает заголовок в динамическую таблицу, а потом отправляет тысячи коротких индексных ссылок. Один байт в сетевом пакете заставляет сервер создать полноценную структуру заголовка в памяти. Повтор операции тысячи раз за один запрос создаёт резкий разрыв между затратами атакующего и расходом памяти на стороне сервера.
Часть атаки, похожая на Slowloris, использует управление потоком в HTTP/2. Протокол позволяет получателю объявлять размер окна, то есть сообщать отправителю, сколько байтов можно передать дальше. В HTTP/2 Bomb клиент задаёт для ответа сервера нулевое окно управления потоком. Сервер не может завершить передачу ответа, поэтому не закрывает поток и не освобождает память, уже выделенную под обработку заголовков.
Чтобы соединение не истекло по таймауту, атакующий периодически отправляет крошечные кадры WINDOW_UPDATE. Сервер видит активность и продолжает держать поток живым, но фактически не может нормально завершить обработку запроса. В результате память остаётся закреплённой за зависшим потоком столько времени, сколько позволяют таймауты и настройки конкретной реализации HTTP/2.
Исследователи подчёркивают, что отдельные элементы атаки не выглядят новыми. HPACK Bomb обсуждали ещё в 2016 году в контексте CVE-2016-6581 . В Apache httpd ранее находили похожие проблемы с истощением памяти в HTTP/2, включая CVE-2025-53020 . Похожие DoS-уязвимости возникали через специально сформированные кадры CONTINUATION и истощение рабочих потоков в соединениях HTTP/2. HTTP/2 Bomb отличается источником усиления нагрузки.
Классическая компрессионная бомба обычно помещает в таблицу крупное значение и многократно ссылается на него. Серверы научились ограничивать общий размер распакованных заголовков, поэтому простое увеличение значения чаще упирается в лимит. В новой схеме заголовок почти пустой. Нагрузка появляется не из-за размера распакованных данных, а из-за служебных структур, которые сервер создаёт вокруг каждой записи. Лимит на размер декодированных заголовков не срабатывает, потому что декодировать почти нечего.
Для серверов, которые ограничивают количество полей заголовков, исследователи нашли обход через Cookie. Спецификация HTTP/2 допускает разделение заголовка Cookie на несколько отдельных полей, чтобы повысить эффективность сжатия. Apache httpd и Envoy в проверенной конфигурации не учитывали фрагменты Cookie как обычные поля при подсчёте лимита. Дальнейший эффект зависел от того, как сервер заново собирает Cookie перед передачей запроса приложению.
Envoy добавляет каждый фрагмент Cookie в буфер. При крупном значении Cookie, на которое ссылаются десятки тысяч раз, логическое усиление достигает примерно 3600:1, а измеренное потребление памяти с учётом накладных расходов поднимается выше. В демонстрации Calif для Envoy 1.37.2 коэффициент усиления составил около 5700:1, а потребление памяти выросло примерно до 32 ГБ за 10 секунд.
Apache httpd ведёт себя иначе и пересобирает объединённую строку Cookie при добавлении каждого фрагмента. Старые копии остаются в памяти до очистки потока, поэтому даже пустой Cookie может давать усиление около 4000:1. В демонстрации Apache httpd 2.4.67 занял около 32 ГБ памяти примерно за 18 секунд.
nginx и Microsoft IIS показали меньший коэффициент усиления, но проблема всё равно приводит к отказу в обслуживании. В тестах Calif nginx 1.29.7 давал около 70:1 и набирал примерно 32 ГБ памяти за 45 секунд. Microsoft IIS на Windows Server 2025 показал около 68:1 и около 64 ГБ памяти за тот же промежуток времени. Для атаки на реальный сервер злоумышленнику не обязательно доводить процесс до аварийного завершения. Более выгодная тактика - удерживать нагрузку чуть ниже порога завершения процесса, загнать систему в swap и резко замедлить обработку остальных запросов.
HTTP/2 Bomb обнаружил OpenAI Codex при анализе серверных кодовых баз. По описанию Calif, модель связала две давно известные идеи в рабочую цепочку и помогла построить комбинированный вариант атаки. Исследователи отдельно отмечают, что после публикации исправляющих коммитов путь от diff-файла до работоспособного эксплойта становится очень коротким: современные ИИ-инструменты уже способны восстановить логику атаки по изменениям в коде.
Calif раскрыла проблему nginx в апреле. Разработчики nginx добавили директиву max_headers и выпустили версию 1.29.8 на следующий день. Директива по умолчанию ограничивает число заголовков значением 1000. Если быстро обновить сервер нельзя, исследователи советуют отключить HTTP/2 директивой http2 off;.
Apache получил уведомление 27 мая. Исправление попало в mod_http2 v2.0.41: фрагменты Cookie теперь учитываются при проверке LimitRequestFields. Патч доступен в отдельном выпуске mod_http2 и в основной ветке httpd, но на момент публикации Calif ещё не входил в стабильный выпуск Apache httpd 2.4.x. При невозможности обновления временная защита сводится к отключению HTTP/2 через Protocols http/1.1.
Снижение LimitRequestFieldSize в Apache может уменьшить ущерб в пределах одного потока, потому что ограничивает размер объединённого Cookie и число его фрагментов. Такой шаг не закрывает проблему полностью: атакующий может распределить нагрузку по нескольким потокам и соединениям. Уменьшение LimitRequestFields против этой схемы не помогает, если сервер не считает повторяющиеся фрагменты Cookie как отдельные поля.
Для Microsoft IIS, Envoy и Cloudflare Pingora на момент публикации Calif готовых исправлений не было. В таких конфигурациях исследователи советуют отключать HTTP/2 там, где это допустимо, или ставить перед уязвимым сервером компонент, который жёстко ограничивает количество заголовков в запросе. Защита должна учитывать общий размер декодированных заголовков и число полей, включая отдельные фрагменты Cookie.
Общее правило для точек терминации HTTP/2 звучит просто: лимит размера заголовков и лимит количества заголовков решают разные задачи. Серверу нужны оба ограничения. Дополнительно инфраструктура должна ограничивать срок жизни зависшего потока, даже если клиент периодически отправляет WINDOW_UPDATE и формально поддерживает активность соединения.
Если обновление и отключение HTTP/2 невозможны, Calif советует ограничивать память рабочих процессов через cgroups, ulimit -v или лимиты контейнеров. Такой подход не устраняет уязвимость, но меняет режим отказа. Лучше быстро завершить один перегруженный worker и запустить новый процесс, чем позволить атакующему удерживать почти всю память сервера и тормозить остальные запросы.
Главный просчёт связан не с одной реализацией, а с тем, как спецификация описывает риск истощения памяти. HPACK учитывает опасность усиления через динамическую таблицу и предлагает ограничивать её размер через SETTINGS_HEADER_TABLE_SIZE. HTTP/2 Bomb показывает другой путь: даже умеренный коэффициент усиления становится опасным, если клиент почти бесплатно держит соединение открытым и закрепляет каждый выделенный байт памяти за незавершённым потоком.
- Источник новости
- www.securitylab.ru
