Исследователи из компаний Netflix и Google выявили (https://github.com/Netflix/security-bulletins/blob/master/ad...) в различных реализациях протокола HTTP/2 восемь уязвимостей, которые позволяют вызвать отказ в обслуживании через отправку определённым образом оформленного потока сетевых запросов. Проблемы в той или иной мере затрагивают большинство HTTP-серверов с поддержкой HTTP/2 и приводят к исчерпанию доступной для рабочего процесса памяти или созданию слишком высокой нагрузки на CPU. Обновления с устранением уязвимостей уже представлены в nginx 1.16.1/1.17.3 (http://mailman.nginx.org/pipermail/nginx-announce/2019/00024...) и H2O 2.2.6 (http://blog.kazuhooku.com/2019/08/h2o-version-226-230-beta2-...), но пока недоступны (http://www.apache.org/dist/httpd/) для Apache httpd и других продуктов (https://www.kb.cert.org/vuls/id/605641/).
Проблемы стали следствием внесённых в протокол HTTP/2 усложнений, связанных с применением бинарных структур, системой лимитирования потоков данных внутри соединений, механизмом приоритезации потоков и наличия ICMP-подобных управляющих сообщений, работающих на уровне соединения HTTP/2 (например, операции ping, сброса и настройки потока). Многие реализации должным образом не ограничивали поток управляющих сообщений, неэффективно организовывали работу очереди приоритетов при обработке запросов или использовали неоптимальные реализации алгоритмов управления потоком.
Большинство выявленных методов атаки сводятся к отправке на сервер определённых запросов, приводящих к генерации большого числа ответов. Если при этом клиент не читает из сокета данные и не разрывает соединение, очередь буферизации ответов на стороне сервера непрерывно заполняется. Подобное поведение создаёт нагрузку на систему управления очередью обработки сетевых соединений и в зависимости от особенностей реализации приводит к исчерпанию доступной памяти или ресурсов CPU.
Выявленные уязвимости:
- CVE-2019-9511 (Data Dribble) - атакующий запрашивает большой объём данных в несколько потоков, манипулируя размером скользящего окна и приоритетом потока, принуждая сервер помещать данные в очередь блоками по 1 байту;
- CVE-2019-9512 (Ping Flood) - атакующий непрерывно отравляет ping-сообщения через соединение HTTP/2, инициируя заполнение на другой стороне внутренней очереди отправленных ответов;- CVE-2019-9513 (Resource Loop) - атакующий создаёт несколько потоков запросов и непрерывно меняет приоритет потоков, вызывая перемешивание дерева приоритетов;
- CVE-2019-9514 (Reset Flood) - атакующий создаёт несколько потоков
и отправляет через каждый поток некорректный запрос, вызывая отправку сервером кадров RST_STREAM, но не принимает их для заполнения очереди ответов;
- CVE-2019-9515 (Settings Flood) - атакующий отправляет поток пустых кадров "SETTINGS", в ответ на которые сервер обязан подтвердить получение каждого запроса;
- CVE-2019-9516 (0-Length Headers Leak) - атакующий отправляет поток заголовков с нулевым именем и нулевым значением, а сервер выделяет для хранения каждого заголовка буфер в памяти и не освобождает его до завершения сеанса;- CVE-2019-9517 (Internal Data Buffering) - атакующий открывает
скользящее окно HTTP/2 для отправки сервером данных без ограничений, но при этом держит окно TCP закрытым, что не позволяет фактически записать данные в сокет. Далее атакующий отправляет запросы, требующие большого ответа;
- CVE-2019-9518 (Empty Frames Flood) - атакующий отправляет поток кадров типа DATA, HEADERS, CONTINUATION или PUSH_PROMISE, но с пустым полезным содержимым и без флага завершения потока. Сервер тратит время на обработку каждого кадра, непропорционально затраченной атакующим полосе пропускания.
URL: https://blog.cloudflare.com/on-the-recent-http-2-dos-attacks/
Новость: https://www.opennet.me/opennews/art.shtml?num=51279
>Многие реализации должным образом не ограничивали поток управляющих сообщений, неэффективно организовывали работу очереди приоритетов при обработке запросов или использовали неоптимальные реализации алгоритмов управления потокомВся суть современного IT: некогда оптимизировать, некогда тестировать, тяп-ляп и в продакшен!
То ли дело деды программировали. Всякие рекурсивные днсы, рипы и прочее до сих пор аукается.Да и в самом http тоже всякого добра хватает, например, передача всех кук на каждый запрос, невозможность заменить gzip сжатие на что-то более адекватное и т.п.
Не всех кук, а только относящихся к текущему домену и пути. Деды не виноваты, что современные веб-девелоперы всегда ставят '/' в качестве пути для всех кук. Со сжатием то же самое - не вина дедов, что браузеры только gzip поддерживают.
Ограничение количества пересылаемых кук по путям, лишь немного ослабляют и оттягивают проблему.Если браузер и так постоянно держит с сервером keep-alive соединение, то нафига на каждый гет пересылать все авторизационные куки?
В сравнении с мегабайтами джаваскрипта на чаждый чих -- все эти куки посто пыль.
Потому что путь нового гет может отличаться, соответственно и набор кук может быть иным. Потому что даже при том же пути набор и значение кук может измениться (яваскриптом или прямыми действиями пользователя).
И потому, что предназначение кук - вовсе не передача данных, используйте инструмент по назначению и всё будет нормально.
Потому что HTTP - это stateless протокол, а keep-alive соединение - просто оптимизация. Сервер, с которым установлено соедиение, с большой вероятностью не обрабатывает запрос сам, а передает дальше, и твои запросы в рамках одного подключения могут обрабатываться разными процесссами, возможно на разных машинах. Если фронтенд (реверс-прокси) сам бы хранил все куки для твоего соединения, то для обслуживания сотен тысяч одновременных соденинений (nginx без проблем тянет такие цифры) потребовалось бы дохрена памяти. При этом нет никакой гарантии, что фронтенд поддерживает keep-alive соединение именно с тобой, а не с проксей, через которую ты ходишь в интернет - в последнем случае твоими куками мог бы воспользоваться другой пользователь прокси.
что за бред с gzip? можно хоть zip, хоть бротли заюзать
походите по крупным сайтам, там поголовно почти везде brotli вместо gzip
Изначально гугловцы так и сделали. Потом оказалось, что в мире слишком много проксей, которые или криво сконфигурированы или в принципе аппаратные и не могут быть перенастроены, которые, встречая не гзипнутый трафик, гзипуют его и перезатирают хедеры.В итоге, на клиент приходит каша из сжатого дважды трафика и неверными хедерами.
Помучавшись с этим, гугловцы откатили поддержку других типов сжатий из http, оставив его только для https.
Аппаратный прокси? Это как? Или просто железка с устаревшей прошивкой?
> Или просто железка с устаревшей прошивкойНе просто "железка с устаревшей прошивкой", а неподдерживаемая, но еще работающая "железка с устаревшей прошивкой", новой прошивки для которой скорее всего никогда уже не будет, но заменить которую стоит много американских денег :(
>>но заменить которую стоит много американских денег :(Поминусуют конечно - но это просто косяк в изначальной концепции. Кто-то купил в архитектуру "странную" железку без контракта на апдейт/техсаппорт и потом все страдают. Типичный случай.
>невозможность заменить gzip сжатие на что-то более
> адекватное и т.п.Это когда 99% http-трафика http://techrights.org/2019/08/10/making-the-web-light/
- ненужный мусор?Да! Есть такая проблема. В http, ога.
Если бы http разрабатывался по современным нормам (кратко: бизнес не ждёт, агиль быстрее!1), проблем было бы на порядок больше. Если бы он вообще удался, ведь в моде ещё и federated.
Весь веб через жoпу сделан.
Например, вебсокеты разрабатывали какие-то недоделанные студенты - там если rfc почитать, то можно все лицо себе фейспалмом разбить.Например: при аутентификации надо взять какую-нибудь случайную строку и сделать из нее base64, который уже пересылается на сервер. И, внимание, после всех манипуляций проверка идет по этой строке - никто обратно base64 не декодирует.
Внимание, вопрос: почему тогда не написали "сгенерируйте строку из символов 1-9a-z="? Все просто - потому, что "уяк, уяк и в продакшен", так как даже не потрудились вычитать текст "стандарта" после того как, очевидно, удалили лишнюю проверку строки.
А таких примеров - масса. Я когда писал демон вебсокет<->сокет, два месяца на веб глядеть не мог, так тошнило от этой криворукости.Или вот GUID (требование RFC - "сгенерируйте GUID"), который именно гуид - но, внимание, нигде нету требования что-то из него вытаскивать или проверять. Он используется просто как текстовая строка!!!
Я спокойно юзал слово "your-*ucking-monkeys" вместо гуида, и оно работало везде.Так что ни разу не удивлен, да. Скорее странно что раньше не раскопали.
Пока ты писал свой идеальный код под Дос, вышел windows 10
а нельзя ли его затолкать туда, откуда он "вышел", и чопик, чопик вбить в эту задницу индусскую - чтоб больше не выходил?И вернуть семерку, которая, хотя бы, не менялась каждый день.
> а нельзя ли его затолкать туда, откуда он "вышел", и чопик, чопик
> вбить в эту задницу индусскую - чтоб больше не выходил?
> И вернуть семерку, которая, хотя бы, не менялась каждый день.Конечно, нельзя. _Ты_ же уже за _это_ заплатил.
Или ты против Рынка??? :-O
в смысле? Я-то как раз за семерку им платил - за десятку и жаба душила бы, и, в общем не нужно низачем - везде где пользуюсь, она досталась бесплатно без смс.
>она досталась бесплатно без смс.Уговорил. Не заплатил. Зато как славно отрабатываешь :-p
Жаба гадюку... Аксиома Эскобара прямо какая-тою
Не вали на разработчиков. Такой переусложнённый протокол невозможно реализовать, не накосячив.
> Не вали на разработчиков. Такой переусложнённый протокол невозможно реализовать, не накосячив.АНБ закладки уровня протокола. Норм, чо.
и зачем они рвались его реализовывать? Иначе гугель выкинет за борт?
Они специально его переусложнили. А теперь виноваты кто угодно кроме них. А те кто решили переусложненный протокол реализовавать сообщники.
Когда rfc приняли, уже поздно, приходится делать что есть.А приняли, потому что Гугл пропихнул.
В той же рассылке nginx критики протокола было много. Но он решает насущную проблему с оверхедом на хендшейки, соответственно экономит проц, соответственно экономит деньги, так что куда деваться.
>Вся суть современного IT: некогда оптимизировать, некогда тестировать, тяп-ляп и в продакшен!звучит как ворчание старого пердуна
>>Вся суть современного IT: некогда оптимизировать, некогда тестировать, тяп-ляп и в продакшен!
> звучит как ворчание старого пердунане перж*ж молодого девляпяпса - и ладно
Вали на гофер и не газифицируй больше наш мелкий водоём.
Вот не надо. В nginx http/2 тестировали ОЧЕНЬ долго.Просто это очень переусложненный протокол, сложность просто катастрофическая. Вот до такого способа DoS-а только что догадались, а ведь протокол существует уже давно.
Шерето! Для хипсторов, в общем. Пусть побетатестят для нас, а мы потом как-нибудь заюзаем.
> CVE-2019-9512 (Ping Flood)Люблю их музыку
>> CVE-2019-9512 (Ping Flood)
> Люблю их музыкуОсобенно хорош их альбом "fire Wall"
All in all you just another port in the firewall.
Отлично разогнали мужики!
Строчку "we don't need no education" можно не переписывать.
Netty уже поправили: https://netty.io/news/2019/08/13/4-1-39-Final.html
Envoy, Golang тоже пофиксили
> атакующий открывает скользящее окно HTTP/2 для отправки сервером данных без ограничений, но при этом держит окно TCP закрытымБугагагага. Ибо нефиг тащить в протокол уровня приложения функции протокола транспортного уровня.
А то, что там уже давно реализованы функции сеансового уровня (TLS), вас не смущает?
Это хотя бы можно оправдать потребностью в обратной совместимости.
наоборот же ж - это ничем оправдать нельзя, и никакой совместимости там в помине нет.обратная совместимость - в starttls.
разделение на уровни условно и придумано самими человеками с целью упрощения понимания/описания сложных систем. и хотя от него больше пользы, чем вреда, но фанатичная вера в непоколебимость этих разделений ни к чему хорошему не приведёт
Разделение имеет своим обоснования. Опровергнуть их аргументами кроме "фанатичной веры", как видно, Вам нечем.
Что же касается данного случая, прививка генов бульдога носорогу привела к необходимости принимать дополнительные меры по синхронизации потока на уровнях HTTP и TCP.
>>необходимости принимать дополнительные меры по синхронизации потока на уровнях HTTP и TCP.Как HTTP к TCP относиться? Они вроде как разного уровня.
Вот именно. Разного уровня, а в http встроили функционал, за который который отвечает TCP. В результате:
> CVE-2019-9517 (Internal Data Buffering) - атакующий открывает скользящее окно HTTP/2 для отправки сервером данных без ограничений, но при этом держит окно TCP закрытым, что не позволяет фактически записать данные в сокет
Согласен процентов на 80. Если бы сделали udp с удержанием соединения - это потребовало бы намного больше затрат. На ipv6 уже лет 20 переходят.
Потому что HTTP/2 - это как systemD от мира протоколов. Осталось protobuf и gRPC прямо в стандарт вхреначить, чтоб уж полный комплект. Чорт, теперь точно вхреначат.
погодите, они разьве еще не в quiRk ?
> Потому что HTTP/2 - это как systemD от мира протоколов.Гугль продавил на хайпе свою реализацию переусложнённого непознаваемого хлама, заражающегои и поражающего всё, к чему прикасается, не пригодную для кооперативной, совместной разработки, в кач-ве стандарта и монополии?
Нет, совсем не похоже на s-d. Роль Микрософта не раскрыта.
> Гугль продавил на хайпе свою реализацию переусложнённого непознаваемого хлама,ну, вообще-то, как ни странно - да. С мордокнижкой на пару - поскольку решает проблемы в основном нового-модного-централизованного инета с тремя сайтами для всех.
Пока еще не монополия, но ждем-с выпиливания 1.x из браузера под каким-нибудь высосанным из пальца предлогом.
> Роль Микрософта не раскрыта.
а в штаны...systemd нам - это тоже microsoft нас...л ?
>> Роль Микрософта не раскрыта.
> а в штаны...systemd нам - это тоже microsoft нас...л ?Вам-то? Вы сами-то не следили за штанишками, когда "бисплатно биз смс"? Ну, ничего-ничего-ничего: один расс не зюстем-двас.
Опубликовали фичи которые они и так знали.
Вот что бывает когда страдают фигнёй.
Полгаю там каждый год теперь будут находить по паре критических багов в реализациях ещё лет 10, как было с остальными бинарными протоколами.
не надейся - это устаревший никому не нужный подход.
через год все уже забудут этот http2 и его проблемы, поскольку будут заняты переходом с немодного, надоевшего, и вот, кстати, уязвимость quic на quic5
А для открытий ссылок http:// - используйте ftp клиенты, файловый менеджер - короче, для чтения текста в интернете используйте что угодно, кроме браузеров, браузеры, они для другого.