Foi apresentada uma nova técnica de ataque nas implementações do protocolo HTTP/2, que simplifica a realização de ataques de DoS por meio da exaustão dos recursos do servidor. A vulnerabilidade recebeu o codinome MadeYouReset e permite, através da manipulação de quadros de controle HTTP/2, inundar o servidor com um grande número de solicitações, contornando as restrições estabelecidas.
A essência do problema é que o cliente pode criar um número muito grande de fluxos processados simultaneamente, independentemente do limite SETTINGS_MAX_CONCURRENT_STREAMS, descartando cada fluxo em sua fase inicial. Essa rejeição faz com que, para enviar uma nova solicitação na conexão HTTP/2 estabelecida, o cliente não precise aguardar uma resposta de servidor e pode imediatamente direcionar um grande fluxo contínuo de solicitações, conforme a largura de banda do canal de comunicação permitir.
O cliente deixa de depender das latências entre o envio de uma solicitação e o recebimento da resposta (RTT, round-trip time) e pode realizar um ataque com custos adicionais mínimos, enquanto o servidor continua a gastar recursos processando as solicitações recebidas. Por exemplo, o servidor realiza a alocação de estruturas de dados para os novos fluxos, a análise da solicitação, a descompactação dos cabeçalhos e a correspondência da URL com o recurso. Em um ataque a proxies reversos, o ataque pode se propagar para os backends para os quais o proxy consegue redirecionar a solicitação antes de seu descarte.
A vulnerabilidade é semelhante ao problema anteriormente conhecido como Rapid Reset (CVE-2023-44487) e é causada pela discrepância na lógica de redefinição dos fluxos, definida na especificação do protocolo HTTP/2 e implementada em produtos finais. A especificação prevê a possibilidade de um fluxo ser descartado pelo cliente e pelo servidor a qualquer momento, mas em muitas implementações do HTTP/2,servidores depois de tal descarte, a solicitação continua sendo processada. A principal diferença no novo ataque é que o descarte do processamento da solicitação é realizado por iniciativa do servidor, e não através do envio de um quadro com a flag RST_STREAM pelo cliente.
O reinício por iniciativa do servidor ocorre quando são recebidas solicitações incorretas, mas tais solicitações são rejeitadas imediatamente, sem iniciar seu processamento completo e sem serem transmitidas ao backend. Para que o ciclo de processamento da solicitação seja completo, o atacante pode primeiro enviar uma solicitação HTTP correta, mas em seguida transmitir uma sequência incorreta de quadros de controle HTTP/2. Essa atividade fará com que o servidor comece a processar a solicitação, mas então, devido a um erro no processamento dos quadros subsequentes, o fluxo será redefinido (transmitindo o fluxo com a solicitação correta para o estado RST_STREAM).
A existência do problema foi confirmada nos servidores HTTP Apache Tomcat, Netty, Eclipse Jetty, Fastly, varnish, lighttpd e Zephyr RTOS. O problema também se manifesta em sites e serviços de servidor da Mozilla. Apache httpd, Apache Traffic Server, Node.js, LiteSpeed e HAProxy não estão vulneráveis ao problema. O status da vulnerabilidade no nginx não foi determinado.
Fonte: opennet.ru
