O que é o Knot Resolver

Knot Resolver é um resolvedor recursivo de DNS open-source com cache desenvolvido pela CZ.NIC (o registrador .cz). Ele resolve consultas DNS em nome de clientes — dispositivos de usuário final, frotas de resolvedores de ISPs e serviços de resolvedor público — e armazena as respostas em cache. Suporta transportes criptografados modernos, incluindo DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) e DNS-over-QUIC (DoQ), e oferece validação DNSSEC e cache agressivo.

É popular em ambientes de grandes ISPs, onde seu rico conjunto de funcionalidades (política programável, DNSSEC, transportes criptografados, cache refinado) e alto desempenho o tornam adequado para atender bases de assinantes muito grandes.

O daemon (kresd) é um serviço de rede de longa duração que fica diretamente exposto a entradas não confiáveis de qualquer host capaz de alcançar sua porta de escuta. Isso torna um bug de corrupção de memória em seu caminho de recepção de pacotes — como o explorado aqui — uma superfície de ataque remotamente acessível e não autenticada: comprometer o resolvedor permite que um atacante forje respostas DNS para todos os clientes downstream, ou seja, redirecione ou intercepte efetivamente todo o tráfego deles.

Causa raiz

kr_recv_stream_data_cb() remonta quadros STREAM do DoQ em um buffer de entrada por conexão (pers_inbuf). Ela aumenta esse buffer com

em vez de definir o tamanho para o novo total. Através de vários quadros, o size rastreado se desvia acima da alocação real. Um quadro final cujo datalen cabe sob o size inflado portanto ignora a realocação, mas o memcpy() subsequente é limitado por esse tamanho inflado — então ele escreve além do final do objeto. O jemalloc mantém o objeto fixado em sua classe de tamanho real, então os bytes excedentes caem no slot adjacente da laje.

Resumo da exploração

Uma sequência de seis quadros em um fluxo percorre pers_inbuf através de cinco classes de tamanho do jemalloc para a classe de 6144 bytes e então transborda para o slot vizinho:

O grooming leve de conexões (abrir várias conexões DoQ, liberar metade pouco antes de disparar) organiza para que slot+1 contenha um manipulador de limpeza do libgnutls. O estouro sobrescreve o ponteiro de despacho desse manipulador, seu argumento e a flag que controla o despacho. Durante o encerramento da conexão, o libgnutls executa

dando controle do ponteiro de instrução (RIP) e do primeiro argumento (RDI). O PoC roteia isso para system() com um ponteiro para uma string de comando fornecida pelo atacante escrita no mesmo slot.

Escopo: ASLR

Este PoC tem como alvo um host com ASLR desabilitado (kernel.randomize_va_space = 0). Com a randomização desligada, os endereços do heap e da libc são determinísticos, então os dois endereços que o exploit precisa (slot+1 e system()) são constantes para uma determinada compilação. Derrotar o ASLR é um problema separado e está intencionalmente fora do escopo aqui — o objetivo é demonstrar a primitiva corrupção-de-memória → fluxo-de-controle → execução-de-código em isolamento.

Como esses endereços são determinísticos, nenhum vazamento de informação é necessário: o exploit é executado completamente pela rede a partir de um host remoto. Os endereços são recuperados uma vez com a etapa probe (abaixo) em qualquer compilação idêntica e então fixados; na compilação de referência eles são slot+1 = 0x7ffff66c5000 e system = 0x7ffff746a490.

Conteúdo

Requer Python 3 com aioquic e netcat no lado do atacante, e gdb no alvo apenas para a etapa única probe.

Uso — shell reverso remoto (sem vazamento de informação)

Esta é a demonstração principal: o exploit é disparado da máquina atacante, pela rede, com os dois endereços determinísticos fixados. Nada é lido do alvo — sem /proc, sem gdb, sem logs.

Cada rodada que acerta chama system() no alvo com um comando de shell reverso; o shell se conecta de volta a --lhost:--lport, onde nc o recebe. Quando chegar, digite na sessão do netcat para controlar o shell:

Os valores --slot1 / --system são recuperados uma vez com a etapa probe em qualquer compilação idêntica; são constantes enquanto o ASLR estiver desligado.

Recuperando os endereços (sonda única)

Os valores --slot1 / --system acima são constantes enquanto o ASLR estiver desligado; recupere-os uma vez em qualquer compilação idêntica. Pré-condição:

poc.py rip --rounds 8 adicionalmente demonstra controle bruto de RIP/RDI (o alvo trava no ponteiro de instrução escolhido pelo atacante).

Confiabilidade

Medido na compilação de referência (Debian 12, 6.3.0-cznic.1, ASLR desligado):

A lacuna é inerente: system() é executado em um heap que o estouro acabou de corromper, então a maioria dos despachos trava o kresd antes que o filho seja gerado. O daemon é reiniciado pelo seu supervisor após cada falha, o endereço é determinístico com ASLR desligado e cada tentativa é independente — então o loop exec simplesmente tenta novamente até que uma acerte (na execução remota acima, um shell chegou na rodada 5). Uma tentativa fracassada é uma falha transitória do worker (DoS). Os parâmetros de grooming --groom 16 --close 8 --qpc 4 são os padrões empiricamente melhores; fechamento mais pesado (por exemplo, --close 16 com --groom 32) colapsa a taxa de acerto.

Ambiente de referência

A geometria das classes de tamanho (seis quadros, payloads de 1200/1440 bytes) e o deslocamento de despacho do libgnutls são específicos desta compilação; outras compilações precisam que os tamanhos de quadro e deslocamentos sejam rederivados.

Linha do tempo da divulgação

Divulgação e licença

Reportado ao fornecedor em 2026-06-08 e lançado em coordenação com a correção oficial (6.4.1, 2026-07-22). Fornecido para testes autorizados, validação defensiva e pesquisa. Não execute contra sistemas que você não possui ou para os quais não tenha autorização explícita para testar.

SPDX-License-Identifier: MIT