Представлена новая техника атаки на реализации протокола HTTP/2, упрощающая проведение атак для вызова отказа в обслуживании через исчерпание ресурсов сервера. Уязвимость получила кодовое имя MadeYouReset и позволяет через манипуляции управляющими кадрами HTTP/2 наводнить сервер большим количеством запросов в обход установленных ограничений. Суть проблемы в том, что клиент может создать очень большое число одновременно обрабатываемых потоков, независимо от лимита SETTINGS_MAX_CONCURRENT_STREAMS, сбрасывая каждый поток на начальном этапе. Подобный сброс приводит к тому, что для отправки нового запроса в установленном соединении HTTP/2 клиенту не требуется жать ответа от сервера и можно сразу направить большой непрерывный поток запросов, насколько позволяет пропускная способность канала связи. Клиент перестаёт зависеть от задержек между отправкой запроса и получением ответа (RTT, round-trip time) и может провести атаку с минимальными накладными расходами, при том что сервер продолжает тратить ресурсы на обработку поступающих запросов. Например, сервер осуществляет выделение структур данных под новые потоки, разбор запроса, распаковку заголовка и сопоставление URL с ресурсом. При атаке на обратные прокси, атака может распространиться на бэкенды, на которые прокси успеет перенаправить запрос до его сброса. Уязвимость напоминает ранее известную проблему Rapid Reset (CVE-2023-44487) и вызвана расхождением логики сброса потоков, определённой в спецификации протокола HTTP/2 и реализованной в конечных продуктах. В спецификации предусмотрена возможность сброса потока клиентом и сервером в любой момент, но во многих реализациях HTTP/2-серверов после подобного сброса запрос продолжает обрабатываться. Ключевым отличием новой атаки является то, что сброс обработки запроса осуществляется по инициативе сервера, а не через отправку клиентом кадра с флагом RST_STREAM. Сброс по инициативе сервера происходит при поступлении некорректных запросов, но подобные запросы отбрасываются сразу без начала их полноценной обработки и без передачи бэкенду. Для того, чтобы добиться полного цикла обработки запроса атакующий вначале может отправить корректный HTTP-запрос, но следом за ним передать некорректную последовательность управляющих кадров HTTP/2. Подобная активность приведёт к тому, что сервер начнёт полноценно обрабатывать запрос, но потом из-за ошибки при обработке следом идущих кадров сбросит поток (переведёт поток с корректным запросом в состояние RST_STREAM).
Наличие проблемы подтверждено в HTTP-серверах Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd, Zephyr RTOS. Проблема проявляется также на сайтах и серверных сервисах Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed и HAProxy проблеме не подвержены. Статус наличия уязвимости в nginx не определён.
Источник: https://www.opennet.ru/opennews/art.shtml?num=63726
Наличие проблемы подтверждено в HTTP-серверах Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd, Zephyr RTOS. Проблема проявляется также на сайтах и серверных сервисах Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed и HAProxy проблеме не подвержены. Статус наличия уязвимости в nginx не определён.
Источник: https://www.opennet.ru/opennews/art.shtml?num=63726