Qifan Zhang

When Routinator encounters a CRL with many entries, it may hang or run out of memory. If Routinator encounters a CRL file with the wrong encoding, it may exit.

When Routinator encounters an RRDP notification file with gaps in the delta entries, it is still accepted and parsed, potentially leading to missing data. If it encounters too many delta entries it may run out of memory.

Routinator runs out of memory when the JSON output is requested many times concurrently. This condition can be triggered maliciously by an attacker by opening a large number of connections to the HTTP server. Additionally Routinator runs into a stack overflow and exits when a payload item with too much metadata is discarded at once. This only affects users that make their HTTP or RTR server available to untrusted networks.

Routinator exits when an rsync URI for a file obtained over RRDP contains a path that cannot be stored on disk, such as too long file names, and folder names that overlap with existing file names.

Uma falha ocorre quando o software é configurado com tanto uma âncora de confiança raiz quanto um `trust-anchor:` adicional para uma zona de ilha de segurança cujo pai é comprovadamente inseguro sob a cadeia raiz. Um agente malicioso pode usar uma resposta NSEC forjada com o bit SOA limpo para enganar o sistema e fazer com que a ilha de confiança configurada seja tratada como insegura. Isso acontece porque o validador DNSSEC aceita e armazena em cache a resposta NSEC insegura, ignorando a validação RRSIG necessária. Esse comportamento é resultado de uma correção anterior relativa a consultas de tipo DS e NSEC de clientes quando existia uma âncora de confiança para aquele nome.

Um problema ocorre quando o software é configurado com tanto uma âncora de confiança raiz quanto um `trust-anchor:` adicional para uma zona de ilha de segurança cujo pai é comprovadamente inseguro sob a cadeia raiz. Um agente mal-intencionado pode entregar uma resposta NXDOMAIN forjada para um nome dentro da ilha, com o `SignerName` do NSEC/SOA RRSIG definido para o pai inseguro. Isso engana o validador para usar a âncora de confiança raiz e, consecutivamente, o pai inseguro, fazendo com que o registro seja tratado como inseguro e negando a existência de registros na ilha de confiança.

Existe um problema onde um Registro de Recurso (RR) SVCB ou HTTPS que preenche o RDATA do formato de fio até a capacidade pode permitir que um parâmetro ECH sobrescreva a pilha. Uma vez ultrapassado o limite, o decodificador base64 pode gravar dados controlados por um invasor de tamanho ilimitado. Isso ocorre quando arquivos de zona são alimentados diretamente ao NSD, como aqueles provenientes de um sistema de provisionamento controlado pelo operador, em vez de arquivos gravados pelo próprio NSD.

Um problema ocorre quando dados base64 são divididos em pedaços de 3 caracteres ou menos, fazendo com que os tokens sejam calculados incorretamente como 0 bytes. Isso permite que um invasor sobrescreva a pilha com até 64K de dados controlados. Isso pode acontecer quando um arquivo de zona é fornecido diretamente ao NSD, como a partir de um sistema de provisionamento controlado pelo operador. Aproximadamente 116,3 mil instâncias foram identificadas globalmente.

Um registro de recurso HIP que preenche o RDATA próximo ou no seu limite e possui outro campo RDATA dname (um servidor HIP Rendezvous) pode sobrescrever a pilha com até 191 bytes de dados controlados por um invasor. Isso ocorre quando um arquivo de zona é fornecido diretamente ao NSD, como por meio de um sistema de provisionamento controlado pelo operador, em vez de ser escrito pelo próprio NSD.

Ataques de complexidade algorítmica, pesquisados como 'ReTrap', podem levar à degradação do serviço quando zonas maliciosas são utilizadas. Esses ataques incluem o TagTrap, onde o mecanismo de correspondência triple(Zone, Algo, KeyTag) é explorado por meio de respostas com inúmeros registros DNSKEY, RRSIG e DS incompatíveis; o DelegationTrap, que causa sobrecarga computacional durante a validação iterativa da cadeia de confiança para domínios profundamente aninhados; o NsecTrap, que força o resolver a validar registros NSEC inválidos excessivos; e o AdditionalTrap, onde a validação DNSSEC padrão da seção ADDITIONAL é utilizada para desperdiçar recursos.

Um problema de degradação de serviço existe no procedimento de leitura TCP/DoT devido à ausência de um limite para leituras consecutivas. Um agente malicioso pode monopolizar todo o loop de eventos de um único worker ao transmitir e manter uma taxa de nomes distintos não armazenados em cache através da conexão TCP/DoT, desde que suas gravações permaneçam à frente do dreno.

Zonas configuradas com `zonemd-check: yes` que estão localizadas abaixo de uma âncora de confiança possuem uma falha onde conteúdos de zona adulterados podem ser servidos ou armazenados em disco antes que a verificação de integridade ZONEMD seja concluída. Isso ocorre devido à resolução assíncrona de registros DS/DNSKEY necessária para a verificação. Se a opção `zonefile:` for utilizada para gravar um arquivo de zona em disco enquanto a verificação ZONEMD falha, os dados adulterados são recarregados na inicialização e permanecem disponíveis até que a próxima verificação seja concluída. Mesmo que a verificação falhe posteriormente, os dados adulterados persistem no disco para recarregamentos futuros.

Itens da lista de controle de acesso configurados como BLOCKED para negar o acesso na porta do protocolo proxy podem ser completamente ignorados. Isso ocorre quando uma conexão é estabelecida via TCP ou TLS e a consulta é enviada duas vezes em uma conexão que permanece aberta.

Em sistemas little-endian, o software compara incorretamente endereços IP com intervalos de controle de acesso. Isso ocorre porque os endereços IPv4 são comparados como números de 32 bits sem sinal usando a endianness do host, enquanto os valores de comparação permanecem na ordem de bytes da rede (big-endian). Para endereços IPv6, o processo envolve quatro comparações separadas de números de 32 bits sem sinal, também falhando em considerar a diferença entre a endianness do host e a ordem de bytes da rede. Consequentemente, endereços IP que deveriam ser permitidos podem ser negados, e aqueles que deveriam ter o acesso negado podem ser permitidos.

Um cliente remoto pode causar a falha do processo serve child do NSD em tipos de compilação de depuração (debugging) ou não-lançamento (non-release). Isso ocorre quando o processo recebe uma mensagem especialmente elaborada contendo um número específico de opções de DNS Cookie, como 17 opções quando o tamanho do payload UDP é 512. A interrupção contínua desses processos pode prejudicar gravemente o desempenho ou levar a uma negação completa do serviço de DNS.

Assinaturas de Registro de Recurso (RRSIGs) com um número insuficiente de rótulos podem permitir a evasão da validação de curinga (wildcard) do DNSSEC. O DNSSEC é um conjunto de extensões que adiciona uma camada de segurança ao Sistema de Nomes de Domínio (DNS), anexando assinaturas digitais aos registros DNS para verificar sua autenticidade.

Ocorre uma falha de validação do DNSSEC quando provas de expansão de curinga (wildcard), especificamente registros NSEC ou NSEC3, são aceitas sem a validação da assinatura. Isso acontece quando a resposta do curinga é um registro CNAME ou DNAME. DNSSEC (Domain Name System Security Extensions) é um conjunto de extensões que adiciona uma camada de segurança ao protocolo DNS, permitindo que as respostas DNS sejam assinadas digitalmente.

Existe uma falha de bypass de contabilização de memória na implementação de DNS-over-QUIC (DoQ) downstream. Quando o DoQ está habilitado, os dois primeiros fluxos bidirecionais em uma nova conexão QUIC (stream id 0 e 4) ignoram completamente o limite `quic-size` por fluxo. Buffers de entrada grandes são alocados após o prefixo de comprimento de 2 bytes ser recebido desses fluxos iniciais, permitindo que um cliente remoto exceda o limite `quic-size` configurado com baixo custo de entrada. Ao enviar um prefixo de comprimento declarado de 65535 bytes e manter os fluxos abertos, um cliente pode fazer com que o sistema aloque aproximadamente o dobro desse valor, resultando em negação de serviço para novos clientes DoQ. Este problema requer que o software seja compilado com suporte a DoQ usando `--with-libngtcp2` e que a `quic-port` esteja configurada para as interfaces de escuta.

Ocorre um estouro de buffer baseado em heap quando uma consulta DNSCrypt é recebida via TCP. A rotina responsável por criptografar a resposta no local não limita o comprimento da resposta em relação ao tamanho do buffer de destino, falhando em aplicar a trava de tamanho utilizada no caminho UDP. Consequentemente, uma resposta superior a 65504 bytes é deslocada 48 bytes para frente dentro de um buffer com capacidade `msg-buffer-size`, resultando em uma gravação além do final da alocação do heap. Isso pode ser desencadeado por uma única consulta criptografada maliciosa, fazendo com que o resolver trave e levando a uma negação de serviço. Este problema requer que o software seja compilado com suporte ao DNSCrypt via `--enable-dnscrypt` e que a cláusula `dnscrypt:` esteja configurada e habilitada para as interfaces de escuta.

Consultas DNS-over-QUIC (DoQ) terminadas pelo cliente não são contabilizadas corretamente, resultando em uma inflação do número de respostas aguardadas para consultas de resolução em andamento. Isso causa a degradação dos serviços de resolução para novos clientes. Um invasor pode explorar isso emitindo consultas DoQ e terminando-as imediatamente usando frames QUIC STOP SENDING, RESET STREAM ou CONNECTION CLOSE. Quando o limite máximo é atingido, novas consultas para resoluções em andamento são descartadas silenciosamente. Este problema requer que o software seja compilado com suporte a DoQ via `--with-libngtcp2` e que o `quic-port` esteja configurado. Além disso, o invasor precisa de múltiplos IPs de origem para ignorar a opção `wait-limit`.