Chrisvest

O componente `NoQuicTokenHandler` não valida tokens adequadamente quando nenhum manipulador de token específico é definido pela aplicação. Especificamente, a função `validateToken()` retorna 0 incondicionalmente, o que a função `QuicheQuicServerCodec.handlePacket()` interpreta como um token válido. Isso permite que um invasor falsifique o endereço IP de origem de uma vítima e inclua quaisquer bytes de token não vazios em um pacote Initial. Consequentemente, o servidor trata o endereço da vítima como validado, ignorando o limite de envio anti-amplificação de 3x definido na RFC 9000 §8.1. Isso possibilita que o servidor reflita fluxos de handshake de tamanho total, como certificados, para a vítima sem as restrições de amplificação padrão.

Uma falha no componente netty-codec-haproxy do framework de aplicação de rede Netty permite que um invasor remoto cause uma condição de Negação de Serviço (DoS). Ao enviar uma mensagem HAProxy especialmente manipulada com um cabeçalho TLV (Type-Length-Value) PP2 TYPE SSL malformado, onde o comprimento é definido abaixo de 5, a função `readNextTLV()` em `HAProxyMessage` dispara uma IndexOutOfBoundsException. Como o `HAProxyMessageDecoder` captura apenas a `HAProxyProtocolException`, essa exceção se propaga, impedindo a liberação de memória retida no buffer de cumulação agrupado, resultando em um vazamento de memória.

Um problema de alocação de memória não controlada existe na função `SslClientHelloHandler.decode()`. Quando um ClientHello não cabe no primeiro registro, o sistema aloca memória ansiosamente usando `ctx.alloc().buffer(handshakeLength)` com base no comprimento de 24 bits do handshake TLS. Como os construtores `SniHandler`, `AbstractSniHandler` e relacionados frequentemente definem `maxClientHelloLength` e `handshakeTimeoutMillis` como 0, a guarda de comprimento é desativada e nenhum tempo limite é agendado. Consequentemente, uma solicitação de 16 MiB ou mais excede o tamanho do chunk agrupado padrão, resultando em uma alocação imediata enorme ou não agrupada que é retida até que o canal seja fechado.

Ocorre um vazamento de descritores de arquivo na função `netty unix socket recvFd` quando um peer envia dois descritores de arquivo simultaneamente via uma mensagem de controle SCM RIGHTS. O sistema aloca um buffer de controle de 24 bytes no Linux de 64 bits, que comporta exatamente uma mensagem de controle contendo dois inteiros. Como o kernel instala ambos os descritores sem disparar a flag `MSG CTRUNC`, uma verificação de comprimento subsequente `cmsg->cmsg len == CMSG LEN(sizeof(int))` falha, pois espera 20 bytes. Isso faz com que a aplicação ignore a lógica que lê o descritor e falhe ao fechar os descritores instalados. O processo então sai do loop de leitura normalmente, resultando no vazamento de dois descritores de arquivo por mensagem. Este problema é acessível via `Epoll`/`KQueue` `DomainSocketChannel` quando a aplicação está configurada com `DomainSocketReadMode.FILE DESCRIPTORS`.

Um invasor remoto pode causar uma Negação de Serviço (DoS) enviando fragmentos de mensagens do Stream Control Transmission Protocol (SCTP) especialmente manipulados e incompletos. O problema ocorre porque o manipulador utiliza `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))` para cada fragmento incompleto, criando um novo CompositeByteBuf que envolve o acumulador anterior. Isso resulta em uma cadeia de compostos com N níveis de profundidade, onde as chamadas `readableBytes()` ou `getBytes()` recursam N níveis. Como não há limites para o número de fragmentos, o total de bytes ou o número de entradas de `streamId` que um invasor pode abrir, um peer que nunca defina a flag `complete` pode causar crescimento ilimitado de memória e consumo excessivo de recursos do sistema.

No framework de aplicação de rede, o `DefaultHttp2Connection.DefaultEndpoint` inicializa `maxActiveStreams` e `maxStreams` como `Integer.MAX VALUE`, enquanto o `Http2Settings` não insere `SETTINGS MAX CONCURRENT STREAMS` por padrão. Se a aplicação não chamar explicitamente `initialSettings().maxConcurrentStreams(n)`, o servidor HTTP/2 não anuncia nem impõe limites para streams simultâneos. Isso permite que uma única conexão TCP crie centenas de milhares de objetos de stream de longa duração, pois cada stream aberto aloca um objeto `DefaultStream`, slots de `PropertyMap`, estado do controlador de fluxo e uma entrada `IntObjectHashMap`. Esta condição também possibilita a amplificação de Rapid-Reset, onde a ausência de um limite simultâneo baixo aumenta a carga de trabalho no backend.

O manipulador RedisArrayAggregator vaza permanentemente buffers de memória direta agrupados quando uma conexão de pipeline Redis é encerrada antes que um agregado de array RESP seja concluído. O manipulador retém mensagens filhas no campo `depths`, mas não define os métodos `channelInactive`, `handlerRemoved` ou `exceptionCaught` para liberá-las durante o encerramento do pipeline. Como os buffers vazados são fatias de chunks do `PooledByteBufAllocator`, eles impedem que esses chunks retornem ao pool de memória direta global da JVM. A rotatividade contínua de conexões por qualquer peer de rede esgota esse pool compartilhado, eventualmente causando falhas de alocação em todos os canais Netty no processo.

A classe `DelegatingDecompressorFrameListener` gerencia a descompressão HTTP/2 utilizando um `EmbeddedChannel` por fluxo para executar codecs de descompressão como gzip, deflate ou zstd. Os blocos descomprimidos são tratados como objetos `ByteBuf` agrupados e passados para um manipulador de cauda `ChannelInboundHandlerAdapter` anônimo, responsável por sua liberação. Um peer remoto pode enviar quadros especificamente criados que fazem com que o controlador de fluxo lance uma exceção, desencadeando um vazamento de recursos. Esse vazamento pode levar a um erro de falta de memória (OutOfMemoryError - OOME), potencialmente derrubando a Java Virtual Machine (JVM).

O codec do protocolo HAProxy PROXY v2 vaza memória nativa ou de heap em cada conexão quando um cliente envia um cabeçalho sintaticamente válido contendo TLVs `PP2 TYPE SSL` (registros de tipo-comprimento-valor) aninhados em profundidade dois ou superior. Isso ocorre durante o caminho de análise bem-sucedido, onde o buffer de acumulação subjacente, um `ByteBuf` agrupado e potencialmente direto alocado pelo canal, permanece permanentemente fixado, mesmo após a liberação do `HAProxyMessage` e a remoção do decodificador.

Netty é um framework de aplicação de rede utilizado para o desenvolvimento de servidores e clientes de protocolo. A função `SimpleTrustManagerFactory.engineGetTrustManagers()` e caminhos relacionados envolvem o X509TrustManager simples fornecido pelo usuário em um X509TrustManagerWrapper. Este wrapper estende o X509ExtendedTrustManager, mas implementa a função `checkServerTrusted(chain, authType, SSLEngine)` de 3 argumentos descartando o `SSLEngine` e chamando o delegado de 2 argumentos. Como o objeto é identificado como um X509ExtendedTrustManager, wrappers internos do SunJSSE ou do Netty não o envolvem novamente para adicionar a identificação de endpoint. Isso resulta na ausência de verificação de nome de host quando um cliente é construído usando `SslContextBuilder.forClient().trustManager(somePlainX509TrustManager)`, mesmo que o `endpointIdentificationAlgorithm` esteja definido como "HTTPS" por padrão, potencialmente permitindo ataques de man-in-the-middle.

Antes de ler a primeira linha de requisição, a função `HttpObjectDecoder` ignora silenciosamente todos os espaços em branco e cada byte para o qual `Character.isISOControl(b)` seja verdadeiro (0x00–0x1F e 0x7F). Este comportamento diverge da RFC 9112 §2.2, que permite apenas que os servidores ignorem linhas CRLF vazias que precedem a linha de requisição para lidar com soluções alternativas de POST do HTTP/1.0. Ao absorver caracteres de controle que não sejam CRLF, como NUL, SOH e STX, o software pode ser explorado para confusão de limite de requisição em transportes pipelined ou multiplexados. Isso ocorre quando um componente de front-end, como um balanceador de carga ou terminador TLS, trata esses bytes de forma diferente do Netty, podendo levar a ataques de dessincronização ou smuggling de requisições.

The issue is related to an unsafe reading of environment files, which could potentially cause a denial of service in Netty. When loaded on a Windows application, Netty attempts to load a file that does not exist. If an attacker creates a large file, the Netty application may crash. A similar issue was previously reported, but the fix was incomplete, as null-bytes were not counted against the input limit. The vulnerability is related to the `BufferedReader.readLine()` function and the `InputStreamReader`, which can fill up the line-buffer with replacement characters when encountering null-bytes.