Violetagg

**Nome do Software Vulnerável e Versões Afetadas** Netty (io.netty:netty-handler) versões 4.2.0.Final até 4.2.16.Final Netty (io.netty:netty-handler) versões anteriores a 4.1.137.Final **Descrição** A verificação de nome de host TLS é desativada no caminho do cliente `SslProvider.OPENSSL` quando um `X509TrustManager` simples (não estendido) é utilizado e o wrapping de trust-manager baseado em Unsafe não está disponível, especificamente no Java 25+. Isso permite que um invasor man-in-the-middle apresente um certificado emitido para um nome de host diferente que é aceito sem validação. **Recomendações** Atualizar Netty (io.netty:netty-handler) versões 4.2.0.Final até 4.2.16.Final para a versão 4.2.17.Final. Atualizar Netty (io.netty:netty-handler) versões anteriores a 4.1.137.Final para a versão 4.1.137.Final.

**Nome do Software Vulnerável e Versões Afetadas** Netty versões anteriores a 4.2.15.Final **Description** O Netty QUIC expõe o token de reset sem estado (stateless reset token) no caminho da rede ao utilizar os geradores padrão de ID de conexão e de token de reset baseados em HMAC. Especificamente, o `HmacSignQuicConnectionIdGenerator` e o `HmacSignQuicResetTokenGenerator` avaliam HMAC-SHA256 usando a mesma chave estática global da JVM `io.netty.handler.codec.quic.Hmac`. Durante a rotação do CID de origem na função `newSourceConnectionIds()`, o CID de origem atual do servidor é usado para produzir o próximo CID. Se o comprimento do CID for de 16 bytes ou mais, os primeiros 16 bytes do novo CID são idênticos ao token de reset sem estado do CID anterior. Como o CID é transmitido nos cabeçalhos QUIC, um invasor no caminho da rede pode observar esses cabeçalhos para derivar o token de reset e realizar um Ataque de Negação de Serviço (DoS) enviando um pacote de Stateless Reset falsificado. **Recommendations** Atualizar para a versão 4.2.15.Final.

**Nome do Software Vulnerável e Versões Afetadas** netty-codec-redis versões anteriores a 4.1.135.Final netty-codec-redis versões anteriores a 4.2.15.Final **Description** Um invasor remoto pode causar uma Negação de Serviço (DoS) ao enviar payloads de Redis especialmente criados através de múltiplas conexões sem a terminação adequada usando `r `. A função `decodeLength()` em `io.netty.handler.codec.redis.RedisDecoder` lê bytes da rede até encontrar um caractere ` `, mas não impõe uma verificação de comprimento máximo durante o buffering. Ao enviar um fluxo contínuo de dígitos sem um caractere ` `, um invasor pode esgotar o pool de memória direta do servidor, resultando em um `OutOfDirectMemoryError` e impedindo que conexões legítimas sejam processadas. **Recommendations** Atualize o netty-codec-redis para a versão 4.1.135.Final ou posterior. Atualize o netty-codec-redis para a versão 4.2.15.Final ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** Netty (versões afetadas não especificadas) **Description** A configuração padrão do `Http3ConnectionHandler` no codec HTTP/3 do Netty não impõe um limite máximo de tamanho de cabeçalho. Quando um peer não especifica `HTTP3 SETTINGS MAX FIELD SECTION SIZE`, a implementação utiliza um limite ilimitado. Isso permite que um agente malicioso envie um número excessivo de cabeçalhos, levando à exaustão de memória e a um Denial of Service via `OutOfMemoryError`. Isso ocorre porque o comportamento padrão segue a RFC 9114, que especifica um padrão ilimitado, ao contrário das implementações HTTP/1.1 e HTTP/2 do Netty, que impõem limites seguros. O limite ilimitado é passado para `Http3FrameCodec#newFactory` e armazenado como `maxHeaderListSize` dentro do `Http3FrameCodec`. **Recommendations** Configure o tamanho máximo da seção de campo de cabeçalho via `Http3Settings` para substituir o limite ilimitado padrão inseguro.

**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 resolvedor DNS no módulo `io.netty.resolver.dns` utiliza um Gerador de Números Pseudo-Aleatórios (PRNG) previsível para gerar IDs de transação DNS e utiliza por padrão uma porta de origem UDP estática. Especificamente, o `DnsQueryIdSpace` gerencia IDs de transação usando `java.util.concurrent.ThreadLocalRandom`, que é um Gerador Congruencial Linear (LCG) previsível. Além disso, o `DnsNameResolverBuilder` define por padrão a `channelStrategy` como `ChannelPerResolver`, que vincula o `DatagramChannel` apenas uma vez, resultando em uma porta de origem estática para todas as consultas subsequentes. Essa combinação reduz a entropia das consultas DNS, permitindo o Envenenamento de Cache DNS (ataque Kaminsky), onde um invasor pode falsificar respostas DNS para redirecionar o tráfego para endereços IP maliciosos, potencialmente levando a ataques de man-in-the-middle. **Recommendations** Atualize para a versão 4.1.135.Final ou posterior. Atualize para a versão 4.2.15.Final ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** netty-handler versões anteriores a 4.1.135.Final netty-handler versões anteriores a 4.2.15.Final **Description** Uma operação de mascaramento incorreta na função `compareTo()` da classe `IpSubnetFilterRule` permite que um invasor ignore as regras de sub-rede IPv6. Especificamente, o método `io.netty.handler.ipfilter.IpSubnetFilterRule#compareTo(java.net.InetSocketAddress)` realiza uma operação AND bit a bit entre o endereço IP de entrada e o `networkAddress` configurado, em vez da `subnetMask`, permitindo que endereços IP públicos válidos ignorem os controles de acesso. **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 (ionetty:netty-resolver-dns) (versões afetadas não especificadas) **Descrição** A validação insuficiente do bailiwick de registros NS em `DnsResolveContext` permite o envenenamento de cache DNS (DNS Cache Poisoning). Um invasor que controle um servidor de nomes autoritativo para um subdomínio pode envenenar o cache de domínios pai. Especificamente, a função `add()` em `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList` aceita qualquer registro NS da seção AUTHORITY se o nome do registro for um sufixo do `questionName`. Consequentemente, a função `handleWithAdditional()` armazena registros A associados da seção ADDITIONAL no `authoritativeDnsServerCache` sob a chave do domínio pai, ignorando as regras de bailiwick—que determinam que um servidor autoritativo para um subdomínio não deve ser confiável para seu pai. A função `cache()` em `io.netty.resolver.dns.DnsResolveContext.AuthoritativeNameServerList` apenas impede o armazenamento em cache para a zona raiz. **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 anteriores a 4.1.135.Final Netty versões anteriores a 4.2.15.Final **Description** O DnsResolveContext do Netty falha ao validar a origem (bailiwick) de registros CNAME em respostas DNS. Na função `buildAliasMap()` dentro de `io.netty.resolver.dns.DnsResolveContext`, o resolvedor processa a seção ANSWER de uma resposta DNS e armazena em cache todos os registros CNAME encontrados sem verificação. Isso pode levar ao Envenenamento de Cache DNS (Bailiwick Bypass), onde um invasor fornece dados DNS não autorizados para um domínio que não controla. **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-codec-redis versões anteriores a 4.1.135.Final netty-codec-redis versões anteriores a 4.2.15.Final **Description** Uma negação de serviço pode ocorrer quando um invasor envia um payload Redis manipulado contendo arrays profundamente aninhados. A função `io.netty.handler.codec.redis.RedisArrayAggregator` agrega partes de RedisMessage em ArrayRedisMessage usando um `Deque<AggregateState>` para rastrear arrays aninhados. Como não há limite para a profundidade máxima desses arrays, um fluxo contínuo de cabeçalhos de arrays aninhados força o servidor a alocar um número massivo de instâncias de `AggregateState` e coleções `ArrayList`. Isso leva à exaustão da memória heap e a um OutOfMemoryError. **Recommendations** 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 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 para desenvolvimento de servidores e clientes de protocolo. O `RedisArrayAggregator` pré-aloca um `ArrayList` com uma capacidade inicial baseada na contagem de elementos de array RESP declarada em um cabeçalho de array. Essa contagem é obtida da rede antes que as mensagens filhas existam, permitindo que um cabeçalho malicioso pequeno solicite uma capacidade inicial enorme. O agregador inicia um novo nível de agregação ao receber um `ArrayHeaderRedisMessage` e executa `new ArrayList<>(length)` para comprimentos positivos sem um máximo configurável. Embora o `RedisDecoder` aplique o `RedisConstants.REDIS MESSAGE MAX LENGTH` para comprimentos de strings em massa, ele não aplica esse limite aos comprimentos de cabeçalho de array. Isso permite que tamanhos de array declarados extremamente grandes passem pela decodificação, levando à reserva imediata de `Object[]` e potencial exaustão de recursos. O problema envolve a função `decodeLength()` em `io.netty.handler.codec.redis.RedisDecoder` e a função `decodeRedisArrayHeader()` em `io.netty.handler.codec.redis.RedisArrayAggregator`. **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 4.2.0.Final até 4.2.14.Final **Descrição** Um problema de exaustão de memória existe no codec HTTP/3 do Netty, dentro do componente `io.netty.handler.codec.http3.QpackDecoder`. A falha ocorre na função `shouldWaitForDynamicTableUpdates()` quando as tabelas dinâmicas QPACK estão habilitadas, mas o `HTTP3 SETTINGS QPACK BLOCKED STREAMS` não é configurado explicitamente, fazendo com que ele assuma o valor padrão 0. Devido a uma verificação condicional incorreta, o limite de streams bloqueados é ignorado, permitindo que um invasor remoto crie um número infinito de streams bloqueados. Como o `QpackDecoder` não remove os streams desbloqueados do mapa `blockedStreams` nem decrementa o contador, o `ReadResumptionListener` de cada stream permanece na memória durante toda a vida útil da conexão. Isso leva a um erro de Out of Memory (OOM), travando a Java Virtual Machine (JVM) e resultando em uma Negação de Serviço. **Recomendações** Atualizar para a versão 4.2.15.Final.