Уязвимость HTTP/2 Bomb, приводящая к исчерпанию оперативной памяти

Для Microsoft IIS и Cloudflare Pingora исправлений пока нет.

забавно

То есть способ атаки был известен ещё два года назад и все ждали когда иишечку доделают?

Файловые бомбы наносят ответный удар! Кто бы мог подумать...

Самое время сделать U-разворот и вернуть http/1.1

Преимуществ во 2 версии особо не вижу, а от 3 лучше бежать как от огня.

То есть способ атаки был известен ещё два года назад и все ждали когда иишечку доделают?

Как же тогда разработчики Angie реализовали защиту от подобного рода атак без ИИ ещё в версии 1.8.0 в 2024 году? Наверное, к ним прилетел разработчик из будущего и рассказал всё.

Как же тогда разработчики Angie реализовали защиту от подобного рода атак без ИИ ещё в версии 1.8.0 в 2024 году?

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

Если посмотреть, как защита от подобного рода атак реализована у других (абзацем выше), то оно ж просто ограничение на количество хедеров. Добавить такое ограничение в Angie могли и не задумываясь о конкретной уязвимости, а просто чтоб было — это ж вполне логичная настройка.

правильно говорил Столяров об этом http/2

Судя по упоминаниям на лоре, Столяров это такой Жириновский от мира IT?

Дак 1.1 тупо ничего не умеет, кроме того чтобы выдавать достаточно лёгкие текстовые .html.

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

Ну а раз уж запихнули дуплекс/вебсокеты и, раз уж значимая часть трафика и так не текст, а картинки/видео, в чём смысл протокол текстовым оставлять? Аргумент про то, что усложняет отладку и telnetом не пообщаешься, не катит, так как у тебя и так 95% соединений уже завёрнуто в TLS, и ты просто так руками ничего не прочитаешь. Оттуда и http/2.

Ну а раз уж протокол бинарный и внутри себя сессиями умеет управлять, зачем полагаться на tcp-стек операционки/сетевого оборудования по пути для управления потоком и гарантиями доставки, если это можно имплементировать и совершенствовать отдельно и перейти на датаграммы? Отсюда и quic/http/3.

Логика развития примерно такова. Да, я тут много что утрировал (бинарные данные всё же не по вебсокетам обычно гоняют, да и ajax лучше когда тебе не нужно держать стейт, для отправки формочек всяких его достаточно) и по временным рамкам оно появлялось немного в другом порядке, но суть в том что 1.1 тупо не нужен в свете более новых версий

По нему если не ошибаюсь и СУБД в локальном софте аля sqlite – сплошная глупость и нинужно.

То есть версия nginx-1.29.8 с исправлением вышла 7 апреля, а уязвимость обнаружена в начале июня? Что-то здесь не так.

@maxcom, @CrX, я к тому это написал, что и без ИИ это можно было найти, пользуясь или головой, или логикой (что тоже считается за пользование головой). Хотелось бы верить, что с появлением ИИ код программ станет безопаснее, быстрее и меньше (но скорее всего нет).

Не повезло мне, у меня только http 1.1 дома работает, свой сервер😅 Не проверить)

Тем временем http1.1 https://http1mustdie.com/

Луддиты видимо, не стали дожидаться. Как раз в 2024 я везде, где мог дотянуться, заменил nginx на angie.

Тем временем http1.1 https://http1mustdie.com/

РКН блокирует. Там что-то вредное.

я к тому это написал, что и без ИИ это можно было найти, пользуясь или головой, или логикой (что тоже считается за пользование головой)

Конечно можно. Да и все уязвимости из предыдущих новостей тоже.

Тут проблема в том, что у человека внимание ограничено и «глаз замыливается». Кода слишком много, а полный аудит всего кода энтузиасты выполнять не спешат — это весьма унылое, скучное, репититативное занятие, которое мало кто согласится делать просто так, только за деньги (и обычно не самые маленькие), а случайно что-то заметить — это надо именно вот в этом месте именно внимание обратить, «хакерский» ум включить. В том смысле, что если людям сказать «вот где-то примерно в этих 500 строках кода есть серьёзная уязвимость», многие очень быстро бы её нашли. Но не знают, куда смотреть, а смотреть везде — долго и муторно. ИИ же лишён этого недостатка — он может в конкретном месте даже и хуже ищет, но он железный и может делать это «просматривая» действительно весь код за раз, не отвлекаясь на что-то более интересное, и не требуя за это полноценной зарплаты.

Хотелось бы верить, что с появлением ИИ код программ станет безопаснее, быстрее и меньше (но скорее всего нет).

Тут двояко. С одной стороны, в существующих проектах ИИ помогает находить уязвимости. Их исправляют, и код программ в среднем становится, конечно же, безопаснее. Иногда, возможно, быстрее и меньше (такую цель ставят всё реже, но всё же).

Однако с появлением ИИ появился и «вайб-кодинг». А соответственно появляются новые программы, код которых заведомо менее безопасен, и уж точно развесистее и обычно медленнее, а главное глючнее.

Получается как бы с одной стороны безопаснее и быстрее, а с другой наоборот. Что перевесит, можно только гадать, простора для аналитики тут мало. Ну я могу предположить, что с улучшением ИИ сгенерированный код будет продолжать становиться всё менее и менее говнокодистым, а значит, негативный фактор уменьшается, в то время как позитивный вроде как пусть медленно, но нарастает. Но уверенности у меня в том, что это приведёт нас ко всему хорошему, уведя от всего плохого, вовсе нет — фиг его знает, какие факторы я упустил из виду (опять же, кстати, из-за ограниченности человеческого внимания).

А что не так с 3?

Легко загуглить и другие публикации на данную тему.

https://portswigger.net/research/http1-must-die

Обычно дают до полугода авторам уязвимых продуктов на то чтобы подготовить исправление и пропушить его на пользователей. То есть сначала сообщают приватно авторам затронутых продуктов, а только потом сообщают публично

Верните мне мой ZX-Spectrum. Всё что мощнее работает только над созданием дыр безопасности.

Туда фуфел свои тентакли запустил, а все, что делает фуфел, гнилое изначально.

ЛУЧШЕ БЫ СОЗДАЛИ БОЛЬШЕ ДЫР УДОВОЛЬСТВИЯ!

Прекрасно. Из-за того, что отдельные севера не могут нормально реализовать HTTP/1, предлагается заставить их реализовать более сложный HTTP/2. Последствия этого решения мы прямо сейчас обсуждаем.

более сложный HTTP/2

А он точно "более сложный"?

Сравни https://www.ietf.org/rfc/rfc9112.html и https://www.ietf.org/rfc/rfc9113.html.

Про фуфел я знаю, но есть же и отделтностоящий стандарт на базе фуфлового, не? Фишки quic выглядят приятно.

А фуфел тем и берет, все будет приятно и с вазелином. Помнишь, как появлялся gmail? Прорывное супер удобное супер фичастое мыло да еще и не для всех по приглашениям, а потом вжух и твоя почта и личные данные безбожно сливаются всем, кто готов за это платить. Бегите, глупцы!

отделтностоящий стандарт на базе фуфлового, не?

Это какой?

Просто разработчики Angie включали мозг чуть сильней, чем разработчики nginx и подумали чуть больше о том, что плохого может прийти по сокету.

Я поэтому и спрашиваю. Сравниваем:

HTTP/1.1:

Повторяем N раз в разных взаимоисключающих ипостастях
    XXX Syntax
    ...
    XXX Parsing
    ...
    Obsolete XXX 
    ...

Между делом втыкаем:
A process for decoding the chunked transfer coding can be represented in pseudo-code as:
   ....
   ....

HTTP/2:

Frame Format
...
DATA Frame
...

Но гмыло это сервис, а хттп3 — протокол

Это какой?

https://en.wikipedia.org/wiki/QUIC

Гугла разработала экспериментальную версию, которая ныне зовется gQUIC. QUIC ныне зовётся стандартизированный IETF протокол и не считается акронимом.

Про хромиум пишут:

It contains a standalone gQUIC and QUIC client and server programs that can be used for testing.

Про фэйсбучное сказано:

mvfst (Pronounced move fast) is a client and server implementation of IETF QUIC protocol in C++ by Facebook.

С акцентом на то, что это IETF версия протокола

ЙЦУКЕНГ фарева! Иделальный шрифт, и ЕГГОГ меня совсем не беспокоит. Ну ладно, Вектор 06-Ц дайте. Или Корвет. На Корвете ДанДари чотенький. И Палочку Щастья

Obsolete XXX

Это где такое? Если 5.2, то там достаточно простое исключение

Между делом втыкаем:

В HTTP/1 хоть псевдокод дали. В HTTP/2 просто An 8.1 HTTP message (request or response) consists of три вида сообщений в почти произвольном порядке. Собирайте как хотите, точнее не как хотите, а внимательно прочитав весь раздел 8.

Так это и пугает, что фуфел поумнел и от сервисов ушел на фундаментальный уровень. Гнать их оттуда ссаными тряпками! Они ничего просто так не делают.

хоть псевдокод дали.

Если дают псевдокод вместо описания формата данных, значит структура данных более сложная по шкале сложности.

Собирайте как хотите, точнее не как хотите, а внимательно прочитав весь раздел 8.

И чем это отличается от HTTP/1.1 ?

вжух и твоя почта и личные данные безбожно сливаются всем, кто готов за это платить

Там какой-то японский мангака загрузил на гугл-диск свои рисунки. Архив. Которые он рисовал. И публиковал в разных журналах.

Гугл просканировал файлы. Обнаружил, что они под какими-то авторскими правами (очевидно издателя). Хотя это был личный диск. Гугл его удалил. И заблокировал аккаунт. Письмо с претензией проигнорировал.

И чем это отличается от HTTP/1.1 ?

Тем, что есть псевдокод, который понятно как реализовывать. А по 8 пункту даже псевдокод с ходу не накидать и особых случаев явно больше.

Протокол http/1.1 фундаментально дырявый, в статье все написано, что сколько пытались фиксить, решения не нашли. Вопрос не в «сложности», а в том, что это уже устаревший протокол, и его необходимо выключить для внешних систем.

устаревший протокол, и его необходимо выключить

надо начинать с тут 🙂

curl -I --http2 https://www.linux.org.ru
HTTP/1.1 200 
Server: QRATOR
Date: Fri, 05 Jun 2026 16:58:27 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=15

curl --http2-prior-knowledge https://www.linux.org.ru
curl: (16) Remote peer returned unexpected data while we expected SETTINGS frame.  Perhaps, peer does not support HTTP/2 properly.

Протокол http/1.1 фундаментально дырявый, в статье все написано

Не фундаментально, а только если запросы от нескольких клиентов запихивать в одно соединение TCP, при этом не измеряя реальный размер запросов, а передавай как есть от клиентов.

С таким походом и линейная модель памяти фундаментально дырявая. Если все процессы в ней запустить без защиты памяти.

ИИ же лишён этого недостатка — он может в конкретном месте даже и хуже ищет, но он железный и может делать это «просматривая» действительно весь код за раз, не отвлекаясь на что-то более интересное, и не требуя за это полноценной зарплаты.

Согласен, конечно. Я и сам пользуюсь ИИ для анализа большого массива документов. Как минимум мне он упрощает предварительный анализ. А иногда и полностью заменяет его. Сам бы я без него анализировал такой объем где-то с неделю-две.

Получается как бы с одной стороны безопаснее и быстрее, а с другой наоборот. Что перевесит, можно только гадать, простора для аналитики тут мало.

Тоже поддерживаю. ИИ развивается так быстро, что аналитику толковую собрать никто не успевает, как она уже устаревает на 2-3 поколения и становится неактуальной. Посмотрим, во что это выльется. Надеюсь не в сюжеты из фантастических фильмов про конец человечества.

Не удивлюсь, если те страшилки по ссылкам написаны при поддержке гугла или ещё каких-то корпорастов, которым неймётся везде внедрить свои протоколы.

Забыли они только упомянуть, что случается это всё при использовании либо каких-то древностей из 90-х, либо ещё какой-то чуши вместо nginx в качестве фронтэнда. nginx же сам всё парсит, и либо отдаёт http/400 если запрос совсем плохой, либо (речь про proxy_pass, т.к. во всех остальных случаях это совсем не актуально) пересылает дальше запрос со скорректированными заголовками, уже не могущими вызвать проблем.

Пересылать запрос дальше в сыром виде он может только если отключена буферизация запроса. Дефолтно она включена, и отключать её может иметь смысл только в крайне редких ситуациях (когда запрос отправляется интерактивно, либо когда он очень большой и не хочется его промежуточно сохранять).

Ну и стоит отметить, что proxy_pass само по себе используется редко, обычно у бэкэндов протокол fastcgi или его аналог.

Так что, подавляющее большинство http/1.x-систем в полной безопасности по отношению к данному явлению.