Marten-Seemann

Um invasor pode causar a alocação excessiva de memória nas implementações de cliente e servidor HTTP/3 ao enviar um quadro HEADERS codificado em QPACK. Este quadro é decodificado em uma seção de trailer de campo grande, contendo inúmeros nomes de campos exclusivos ou valores extensos. O sistema constrói um `http.Header` para o `http.Request` ou `http.Response`, mas impõe limites apenas ao tamanho do quadro HEADERS compactado, e não à seção de campo decodificada. Essa discrepância permite que um quadro maliciosamente elaborado se expanda até 50 vezes seu tamanho codificado usando entradas de tabela estática QPACK, levando à exaustão de memória e a um estado de negação de serviço (DoS).

Um atacante pode causar consumo ilimitado de memória ao criar e fechar repetidamente vários streams WebTransport. Os streams fechados não eram removidos de um mapa interno de sessão, impedindo a coleta de lixo de seus recursos. Um par malicioso pode explorar isso abrindo e fechando um grande número de streams, resultando em crescimento contínuo de memória proporcional ao número de streams fechados. O software mantém um mapa interno que rastreia os streams WebTransport, e as versões afetadas não removiam as entradas dos streams fechados deste mapa.

Um par malicioso pode causar uma negação de serviço no webtransport-go ao impedir ou atrasar indefinidamente o encerramento da sessão WebTransport. Especificamente, um par pode reter o crédito de controle de fluxo QUIC no fluxo CONNECT, bloqueando a transmissão da cápsula WT CLOSE SESSION e fazendo com que a operação de encerramento fique travada. O protocolo WebTransport sinaliza o encerramento da sessão enviando uma cápsula WT CLOSE SESSION no fluxo CONNECT. As versões afetadas ficavam bloqueadas indefinidamente enquanto aguardavam crédito suficiente de controle de fluxo QUIC do par.

A implementação de sessão do webtransport-go é suscetível ao consumo excessivo de memória. Um atacante pode enviar uma cápsula `WT CLOSE SESSION` contendo uma Mensagem de Erro de Aplicação excessivamente grande. A implementação não impõe o limite de 1024 bytes exigido pelo draft neste campo, permitindo que um atacante envie um payload de mensagem arbitrariamente grande que é totalmente lido e armazenado na memória. Isso permite que um atacante consuma uma quantidade arbitrária de memória, exigindo a transmissão completa do payload para alcançar o consumo de memória.

A lógica de recuperação de perda para pacotes de sondagem de caminho no quic-go pode ser explorada por um cliente QUIC malicioso para provocar um desreferenciamento de ponteiro nulo. Isso é conseguido enviando pacotes QUIC válidos de diferentes endereços remotos, acionando a lógica de validação de caminho e fazendo com que o servidor envie pacotes de sondagem de caminho, seguido pelo envio de ACKs especificamente construídos para os pacotes recebidos do servidor.

Nome do software vulnerável e versões afetadas: versões do quic-go anteriores à 0.48.2 Descrição: Um invasor fora do caminho pode injetar um pacote ICMP “Packet Too Large”, interrompendo uma conexão QUIC ao definir o valor de MTU para menos de 1200 bytes. Isso pode ser feito após a conclusão do handshake, contornando qualquer fallback de TCP. O invasor precisa conhecer o endereço IP e a porta do cliente para realizar o ataque. Recomendações: Para versões anteriores à 0.48.2, atualize para a versão 0.48.2 para corrigir a vulnerabilidade. Como solução temporária, considere usar `IP PMTUDISC PROBE` em vez de `IP PMTUDISC DO` para desativar o rastreamento de MTU do kernel. Como alternativa, use o iptables para descartar pacotes ICMP “Unreachable” (inacessível) para minimizar o risco de exploração.

O problema está relacionado à implementação do protocolo QUIC no quic-go, onde um invasor pode fazer com que o seu par fique sem memória enviando um grande número de quadros `NEW CONNECTION ID` que retiram IDs de conexão antigas. O receptor deve responder a cada quadro de aposentadoria com um quadro `RETIRE CONNECTION ID`. No entanto, o invasor pode impedir que o receptor envie esses quadros `RETIRE CONNECTION ID` colapsando a janela de congestionamento do par e manipulando a estimativa de RTT do par.

O problema está relacionado ao armazenamento ilimitado de informações relacionadas à aposentadoria de IDs de conexão, o que pode levar ao consumo excessivo de recursos. Cada conexão QUIC possui um conjunto de identificadores de conexão (IDs). Os terminais declaram o número de IDs de conexão ativas que estão dispostos a suportar usando o parâmetro de transporte `active connection id limit`. O par pode criar novos IDs usando um quadro “NEW CONNECTION ID”, mas deve permanecer dentro do limite de IDs ativos. Isso é feito por meio da aposentadoria de IDs antigos: o terminal envia um ‘NEW CONNECTION ID’ que inclui um valor no campo `retire prior to`, o que gera um quadro “RETIRE CONNECTION ID” como confirmação. Um invasor remoto não autenticado pode explorar a vulnerabilidade enviando quadros “NEW CONNECTION ID” e manipulando a conexão de modo que os quadros “RETIRE CONNECTION ID” só possam ser enviados a uma taxa mais lenta do que a de recebimento, levando ao armazenamento de informações relacionadas a IDs de conexão em uma fila ilimitada.

Um invasor pode fazer com que seu par fique sem memória enviando um grande número de quadros `PATH CHALLENGE`. O destinatário deve responder a cada quadro `PATH CHALLENGE` com um quadro `PATH RESPONSE`. No entanto, o invasor pode impedir que o destinatário envie a maioria desses quadros `PATH RESPONSE` colapsando a janela de congestionamento do par e manipulando a estimativa de RTT do par.

The issue is related to unbounded queuing of path validation messages, which could lead to excessive resource consumption. QUIC path validation requires that the recipient of a `PATH CHALLENGE` frame responds by sending a `PATH RESPONSE`. An unauthenticated remote attacker can exploit this by sending `PATH CHALLENGE` frames and manipulating the connection, such as restricting the peer's congestion window size, so that `PATH RESPONSE` frames can only be sent at a slower rate than they are received, leading to storage of path validation data in an unbounded queue.

The QUIC stack, as used by h2o, is susceptible to a state exhaustion attack. When h2o is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause h2o to abort due to memory exhaustion. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC.

The issue arises from serializing an ACK frame after the CRYPTO frame, allowing a node to complete the handshake. This can trigger a nil pointer dereference when the node attempts to drop the Handshake packet number space, leading to a panic. An attacker can bring down a quic-go node with minimal effort by completing the QUIC handshake, which requires sending and receiving only a few packets.

A malicious actor can store an arbitrary amount of data in a remote node's memory by sending the node a message with a signed peer record. This memory does not get garbage collected, and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack, where the attacker could bring down nodes over a period of time, depending on the node resources. For example, a go-libp2p node on a virtual server with 4 GB of memory can be brought down in about 90 seconds.

A malicious peer can use large RSA keys to run a resource exhaustion attack and force a node to spend time doing signature verification of the large key. This issue is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p now restricts RSA keys to <= 8192 bits.