Chrisvest

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Description** 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. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Description** 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. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Descrição** 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. **Recomendações** Atualize para a versão 4.1.135.Final. Atualize para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** netty-codec-http2 versões anteriores a 4.1.135.Final netty-codec-http2 versões anteriores a 4.2.15.Final **Descrição** 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). **Recomendações** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Description** 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. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** netty-transport-sctp versões anteriores a 4.1.135.Final netty-transport-sctp versões anteriores a 4.2.15.Final **Description** Netty é um framework de aplicação de rede para desenvolvimento de servidores e clientes de protocolo. Existe uma falha onde o manipulador processa fragmentos de SctpMessage não completos executando `fragments.put(streamId, Unpooled.wrappedBuffer(frag, byteBuf))`, o que envolve o acumulador anterior e a nova fatia em um novo CompositeByteBuf a cada vez. Isso cria uma cadeia de compostos de profundidade N após N fragmentos, fazendo com que as funções `readableBytes()` e `getBytes()` façam recursão em N níveis. Como não há limite para o número de fragmentos, bytes totais ou o número de identificadores `streamId` que um invasor pode abrir, um peer que nunca define a flag `complete` pode expandir essa estrutura indefinidamente usando pequenos chunks de DATA de 1 byte. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Description** 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. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final. Como mitigação temporária, chame explicitamente `initialSettings().maxConcurrentStreams(n)` para definir um limite de streams simultâneos.

**Nome do Software Vulnerável e Versões Afetadas** netty-codec-haproxy versões anteriores a 4.1.135.Final netty-codec-haproxy versões anteriores a 4.2.15.Final **Description** Existe um problema ao decodificar um TLV (Type-Length-Value) PP2 TYPE SSL onde a função `readNextTLV()` em `HAProxyMessage` chama `header.retainedSlice(header.readerIndex(), length)` antes de ler o campo de cliente de 1 byte e o campo de verificação de 4 bytes. Se o comprimento do TLV for definido como inferior a 5, as operações subsequentes `readByte` ou `readInt` disparam uma IndexOutOfBoundsException. Como o `HAProxyMessageDecoder` apenas trata `HAProxyProtocolException` durante este processo, a IndexOutOfBoundsException se propaga, impedindo que a fatia retida no buffer de acumulação agrupado seja liberada. **Recommendations** Atualizar para a versão 4.1.135.Final. Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty (ionettyincubatorcodecquic) (versões afetadas não especificadas) **Descrição** 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. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Netty (ionetty:netty-handler) (versões afetadas não especificadas) **Descrição** 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. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Nome do Software Vulnerável e Versões Afetadas** Netty (versões afetadas não especificadas) **Descrição** 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`. **Recomendações** No momento, não há informações sobre uma versão mais recente que contenha a correção para esta vulnerabilidade.

**Name of the Vulnerable Software and Affected Versions** Netty versions up to and including 4.1.118.Final **Description** 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. **Recommendations** For Netty versions up to and including 4.1.118.Final, consider updating to a version that includes the complete fix for this issue, as the current fix is incomplete. As a temporary workaround, consider restricting access to the vulnerable `BufferedReader.readLine()` function or the `InputStreamReader` to minimize the risk of exploitation. Additionally, avoid using the `InputStreamReader` with files that may contain null-bytes, as this can trigger the vulnerability. At the moment, there is no information about a newer version that contains a fix for this vulnerability.