Суть проблемы в том, что клиент может создать очень большое число одновременно обрабатываемых потоков, независимо от лимита 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, h2o, pingora, BIND (в реализации DNS over HTTPS), Zephyr RTOS. Проблема проявляется также на сайтах и серверных сервисах Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed, Hyper и HAProxy проблеме не подвержены. Статус наличия уязвимости в nginx не определён.
Источник: https://www.opennet.ru/opennews/art.shtml?num=63726
(opennet.ru, основная лента)