Mit o3 eine Remote-0-Day in der Linux-SMB-Implementierung entdeckt

• Es wird die Erfahrung geteilt, mit dem OpenAI-o3-Modell eine Remote-0-Day-Sicherheitslücke (CVE-2025-37899) in der SMB-Implementierung des Linux-Kernels entdeckt zu haben
• Beim Benchmarking der LLM-Analysefähigkeiten für den ksmbd-Code wurde die Leistung des LLM anhand einer bereits zuvor manuell gefundenen Schwachstelle verglichen
• Im Prozess der Schwachstellenerkennung wurde der Kontext funktionsweise aufgebaut und mit passenden Prompts versehen, damit o3 die Schwachstelle erkennen konnte
• Die Versuchsergebnisse zeigen, dass o3 im Vergleich zu bisherigen LLMs eine 2- bis 3-mal höhere Genauigkeit bei der Erkennung von Schwachstellen erreichte und zugleich automatisch einen neuartigen Use-after-free-Bug entdeckte
• LLMs, insbesondere neuere Modelle wie o3, zeigen bei Code-Audits und der Schwachstellenforschung eine dem menschlichen Vorgehen ähnliche Flexibilität und Kreativität, wodurch ihr praktischer Nutzen steigt

---

Einleitung

In diesem Beitrag wird vorgestellt, wie mit OpenAIs o3-Modell eine Remote-0-Day-Schwachstelle in der SMB-Implementierung des Linux-Kernels (ksmbd) gefunden wurde. Verwendet wurde lediglich die o3-API; das Experiment lief ohne zusätzliche Frameworks oder Tools. ksmbd ist ein Server innerhalb des Linux-Kernels, der das SMB3-Protokoll implementiert und Netzwerk-Dateifreigaben bereitstellt. Ausgehend von einem begonnenen Schwachstellen-Audit als Abwechslung zur LLM-Entwicklung wurde ein Benchmark durchgeführt, um zu prüfen, wie gut o3 reale Bugs finden kann. Der Schwerpunkt liegt dabei besonders auf der von o3 gefundenen Zero-Day-Schwachstelle CVE-2025-37899.

Bei dieser Schwachstelle handelt es sich um ein Use-after-free-Problem, das bei der Verarbeitung des SMB-Befehls logoff auftritt. Dafür ist ein Verständnis von gleichzeitigen Verbindungen zum Server und der Art erforderlich, wie bestimmte Objekte von mehreren Threads gemeinsam genutzt werden. o3 erkannte die Schwachstelle, indem es diese Nebenläufigkeitsprobleme und Fehler in der Objektverwaltung im Kontext erfasste. Dies ist der erste öffentlich bekannte Fall, in dem ein LLM eine Schwachstelle dieses Typs entdeckt hat.

Die zentrale Aussage ist, dass o3 einen deutlichen Sprung bei den Codeanalyse- und logischen Fähigkeiten von LLMs zeigt und dass Schwachstellenforscher diese Entwicklung unbedingt beachten sollten. LLMs ersetzen keine Experten, deuten aber bereits darauf hin, dass sie sich zu Werkzeugen entwickelt haben, die die Produktivität und Effizienz von Experten drastisch steigern. Bei Codebasen unter 10.000 Zeilen kann o3 bei der Erkennung und Behebung der meisten Probleme praktisch hilfreiche Unterstützung leisten.

Benchmarking von o3 mit CVE-2025-37778

Hintergrund und Ziel des Benchmarks

Zunächst wurde die manuell entdeckte Schwachstelle CVE-2025-37778 (im Folgenden die Kerberos-Authentifizierungsschwachstelle) als Referenzpunkt verwendet, um die Fähigkeiten von o3 zur Schwachstellenerkennung zu bewerten. Dabei handelt es sich um ein Problem, bei dem im Client-Authentifizierungsprozess unter bestimmten Bedingungen des Sitzungszustands ein Use-after-free auftritt.

• Wenn der Sitzungszustand SMB2_SESSION_VALID ist, wird das Benutzerobjekt aus dem Speicher freigegeben
• Schlägt die Authentifizierung danach fehl, wird das Benutzerobjekt nicht erneut initialisiert, und ein Zugriff in diesem Zustand führt zu einem Use-after-free
• Um den gesamten betroffenen Pfad nachzuvollziehen, müssen etwa 3.300 Codezeilen verfolgt werden, was es zu einer Benchmark-Aufgabe mit angemessenem Schwierigkeitsgrad macht

Aufbau des Analysekontexts

Im Experiment wurde aus Sicht eines realen automatisierten Systems zur Schwachstellenerkennung der dem LLM zu gebende Kontext (Codebereich) sorgfältig zusammengestellt. Pro SMB-Befehlshandler wurden die wichtigsten Funktionen und Unterfunktionen bis zu einer Call-Tiefe von 3 Ebenen einbezogen, sodass sämtlicher logisch zusammenhängender Code als Eingabe vorlag (insgesamt 3,3k LoC, etwa 27k Tokens). Auch Funktionen für Datenparsing, Request-Verzweigung und Verbindungsabbau mussten enthalten sein, um belastbare Ergebnisse zu erhalten.

Die konkret verwendeten Prompts und Eingabematerialien sind im zugehörigen GitHub-Repository einsehbar. Dem LLM wurden dabei die folgenden Bedingungen gegeben:

• klare Anweisung, eine Use-after-free-Schwachstelle zu erkennen
• kurze Erklärung der Grundstruktur von ksmbd und des Bedrohungsmodells
• Einsatz lenkender Prompts zur Vermeidung von False Positives

Die eigentlichen Abfragen wurden mit dem llm-Kommandozeilentool wiederholt ausgeführt, um die Versuchsergebnisse zu sammeln (N=100).

Ergebnisse des Benchmark-Experiments

• o3: erkannte die Kerberos-Authentifizierungsschwachstelle 8-mal in 100 Versuchen, verfehlte sie 66-mal und meldete 28-mal False Positives
• Claude Sonnet 3.7: erkannte sie nur 3-mal
• Claude Sonnet 3.5: scheiterte in allen 100 Versuchen an der Erkennung

Damit erzielte o3 im Vergleich zu bisherigen LLMs letztlich eine mehr als 2- bis 3-fach höhere Genauigkeit. Außerdem wirken die tatsächlichen Ausgaben von o3 knapp und präzise, ähnlich wie ein zusammenfassender Bericht eines menschlichen Sicherheitsforschers. Die Ergebnisse von Sonnet 3.7 hinterlassen dagegen eher den Eindruck eines prozessorientierten Arbeitsprotokolls, was sowohl Vor- als auch Nachteile hat.

Entdeckung einer echten 0-Day (CVE-2025-37899) mit o3

Experiment in einer Umgebung mit großem Code-Input

Zusätzlich zur Kerberos-Schwachstelle wurde versucht, mit o3 den gesamten Satz an SMB-Befehlshandlern (etwa 9.000 Zeilen) umfassend auf Schwachstellen zu prüfen. Verschiedene Handler sowie Code für Verbindungsaufbau und -abbau wurden zusammengefasst, sodass insgesamt etwa 12k LoC (rund 100.000 Tokens) auf einmal eingegeben wurden. Bei 100 Wiederholungen wurde die Kerberos-Authentifizierungsschwachstelle nur ein einziges Mal erkannt, was den Leistungsabfall klar zeigt; das Hauptziel war hier jedoch, die Einsetzbarkeit von LLMs über einen größeren Codeumfang hinweg zu erproben.

Neue Schwachstelle, die in diesem Experiment gefunden wurde

Dabei stellte sich heraus, dass o3 neben der Kerberos-Authentifizierung noch einen neu entdeckten Use-after-free-Bug fand. Es handelt sich um ein Nebenläufigkeitsproblem im logoff-Handler einer Sitzung: Zwei Threads greifen bei gleichzeitigen Verbindungen gemeinsam auf das user-Objekt einer Sitzung zu, wobei ein Thread das Objekt freigibt, während der andere es weiter referenzieren kann.

Zusammenfassung des automatischen Schwachstellenberichts von o3

• Zwei Worker-Threads wirken zusammen: Einer führt eine Sitzungsfreigabe (logoff) aus und gibt dabei das user-Objekt aus dem Speicher frei, während der andere dieses user-Objekt in der bestehenden Sitzung weiter verwendet
• Erfolgt unmittelbar nach der Freigabe (bevor auf NULL initialisiert wurde) über einen anderen Pfad noch eine Dereferenzierung, entsteht ein klassisches Use-after-free
• Je nach Timing kann auch ein DoS durch eine NULL-Dereferenzierung auftreten
• Dies kann zu Beschädigungen des Kernel-Speichers und zur Ausführung beliebigen Codes führen

Erkenntnisse aus dem automatischen Bericht

Aus diesem automatischen Bericht wurde deutlich, dass die Korrekturmethode der bestehenden Kerberos-Authentifizierungsschwachstelle (direktes Setzen auf NULL nach der Freigabe) im Fall der Logoff-Verarbeitung keine grundlegende Lösung ist. Für Sicherheit müssen also Sitzungsbindung und Angriffsvektoren zwischen Threads berücksichtigt werden. Auch o3 erkannte dies in einigen Berichten und konnte nachweislich eine „stärkere“ Abhilfemaßnahme vorschlagen.

Fazit

LLMs, insbesondere neuere Modelle wie o3, zeigen bei der kreativen und flexiblen Analyse von Code eine Leistung, die menschlichen Sicherheitsforschern deutlich näher kommt als frühere Verfahren. Bis vor Kurzem wurde diese Möglichkeit eher theoretisch diskutiert, doch o3 ist das erste Modell, das in realen Fällen ein praktisch hilfreiches Niveau erreicht hat. Natürlich gibt es auch bei o3 weiterhin Fehlalarme und Übersehungen, doch die Wahrscheinlichkeit, tatsächlich nützliche Ergebnisse zu liefern, ist deutlich gestiegen, sodass sich der produktive Einsatz nun lohnt. Jetzt ist der Zeitpunkt, an dem Schwachstellenforscher und Entwickler Wege finden sollten, LLMs effizient in ihren Arbeitsablauf zu integrieren.

[GN⁺]

Hacker-News-Kommentare

• Der Autor erklärt, dass er das Projekt verwaltet, indem er System-Prompts, Hintergrundinformationen und Hilfsbefehle jeweils als separate .prompt-Dateien organisiert und diese über llm ausführt.
  Ich habe den Eindruck, dass diese strukturierte Art, LLMs zu nutzen, zeigt, dass man dafür wie bei anderen Engineering-Tools sorgfältiges architektonisches Denken und eine fein austarierte Spezifikation braucht.
  Das zugehörige Projekt ist hier zu finden.

  • Interessant und irgendwie komisch fand ich, dass der Autor zu diesem Teil ehrlich sagt: "Eigentlich basiert mein gesamter System-Prompt auf Vermutungen und hat mit Wissenschaft oder Engineering wenig zu tun."

  • Es gibt zwar verschiedene Arten, Prompts zu schreiben, aber es fehlt an brauchbaren Maßstäben, um sie wirklich zu evaluieren oder zu vergleichen, sodass es sich eher wie improvisiertes Beschwören anfühlt.
    Zum Beispiel Anweisungen wie "Du bist ein Experte für das Finden von Schwachstellen", "Nenne mir nur echte und keine erfundenen Schwachstellen" oder das Trennen per beliebigen HTML-Tags, von denen man vermutet, dass das Modell gut darauf reagiert.
    Ich frage mich, wo dabei eigentlich der Engineering-Anteil steckt.

  • Ich finde es amüsant, dass man Engineering-Prinzipien heranzieht, um ein im Kern instabiles und unvorhersehbares System kontrollieren zu wollen.
    Für solche Prompts wäre die Bezeichnung „Hinweise“ vielleicht passender.
    Praktisch alle heutigen LLMs ignorieren Prompts oft, selbst wenn diese widersprüchlich sind, weil ihr eigentliches Ziel darin besteht, auf jeden Fall eine Antwort zu liefern, unabhängig davon, ob sie wahr ist oder nicht.

• In dem Beitrag wurde ein Signal-Rausch-Verhältnis von etwa 1:50 erwähnt; ich denke, dass der Autor sinnvolle Signale gut herausfiltern konnte, weil er die Codebasis gut kennt.
  Gerade dieser Teil, also die Automatisierung der Erkennung sinnvoller Signale, scheint mir der eigentliche große Gewinn beim Einsatz von LLMs zu sein, deshalb werde ich die weitere Entwicklung aufmerksam verfolgen.

  • Wir entwickeln gerade ein System, das dieses Signal-Rausch-Verhältnis verbessern soll, und benchmarken dabei auch einige der derzeit populären Software-Agenten direkt.
    Die Ergebnisstreuung ist sehr groß, und wir planen, alle Versuchsergebnisse auf einer bald stattfindenden Konferenz offenzulegen.
    Das dürfte einen guten Überblick über den aktuellen Stand der Branche geben.

  • Mir kam vor ein paar Tagen der Gedanke, ob man nicht die gesamte Historie des Linux-Kernels – alle git-Änderungen, Mailinglisten usw. – nutzen könnte, um daraus ein Fine-Tuning-Modell zu entwickeln.
    Ein solches LLM könnte dann vielleicht eher einer synthetischen Version des Gespürs von Entwicklern nahekommen, die den Code tatsächlich über lange Zeit bearbeitet haben.
    Vieles ließe sich wohl schon allein mit großem Kontextfenster abdecken, und manche Codebasen überschreiten nur mit dem Code selbst bereits 200.000 Token, daher halte ich das für denkbar.

  • Ein Verhältnis von 1:50 ist in einer Situation wie „die Nadel im Heuhaufen finden“ eine ausgesprochen gute Trefferquote.

  • Wenn ein LLM selbst Harnesses und Proof-of-Concept-Tests schreiben würde, um jede vermutete Schwachstelle zu belegen, ließe sich das Signal-Rausch-Verhältnis voraussichtlich stark verbessern.
    Schade nur, dass eine solche Automatisierung derzeit noch ziemlich teuer ist.

• Am beeindruckendsten fand ich, dass der Autor selbst die Schwachstellensuche für mehrere LLM-Modelle jeweils 100-mal wiederholt hat.
  Das ist ein deutlich höherer Ressourceneinsatz als bei den meisten Problemen, für die ich bisher LLMs verwendet habe; jetzt überlege ich, ob ich dem Modell auch einmal stumpfes Wiederholen überlassen sollte.

  • Am Ende lautet das Fazit: Man braucht viel Geld.

  • Zero-Day-Schwachstellen lassen sich für beträchtliche Summen verkaufen, und auch mit Bug-Bounties kann man Geld verdienen.
    Die Nutzungskosten von LLMs sind im Vergleich zu solchen Belohnungen verschwindend gering.
    Ich erwarte, dass eine künftige Sicherheitslandschaft mit nahezu auf null gesunkenen Inferenzkosten völlig anders aussehen wird.

  • 100 Ausführungen pro Modell bedeuten auch einen erheblichen Energieverbrauch.
    Wenn das Auffinden einer typischen Schwachstelle in C-Code nur mit einem derart hohen Ressourceneinsatz gelingt, verliert das für mich an Bedeutung und wirkt eher wie ein Beleg für Verschwendung und Luxus.
    Gerade in einer globalen Klimakrise macht mir der Gedanke Sorgen, dass wir wie in den 1950er-Jahren weiterhin Ressourcen für Dinge mit fraglichem Wert verheizen.

• Da Claude kein eigenes Scratchpad für Zwischengedanken hatte, scheint sich im Ergebnis der Denkprozess mit dem eigentlichen Bericht vermischt zu haben.
  Ich würde gern experimentieren, wie sehr sich Claude verändert, wenn man ihm offiziell einen Raum zum Ordnen seiner Gedanken gibt.
  Dass o3 die Kernaussagen verdichtet und fast wie ein von Menschen geschriebener Bug-Report vermittelt, während Sonnet 3.7 eher Spuren innerer Gedankengänge oder Arbeitslogs hinterlässt, passt aus meiner Sicht in denselben Zusammenhang.

  • Ich habe o3, 3.7 und Gemini 2.5 Pro selbst ausprobiert, und mein Eindruck ist, dass o3 in einer ganz anderen Liga spielt.
    Die Benchmark-Werte mögen auf den ersten Blick nicht riesig unterschiedlich wirken, aber je komplexer die Aufgabe, desto bedeutender wird dieser Abstand.
    Ich frage mich, warum das Modell zwar schon im vergangenen November angekündigt, aber erst vor etwa einem Monat veröffentlicht wurde – vermutlich wegen Sicherheitsaspekten –, und ich warte schon gespannt auf o4.

  • Mich würde interessieren, ob jemand Beispiele, Papers oder Links empfehlen kann, in denen „Scratchpads“ in der Forschung genutzt wurden.

• Ich mag diese Passage, weil sie das Wesen von Prompt Engineering sehr gut zusammenfasst.
  Besonders der Teil: "Ich habe mein Bestes getan, um zu verhindern, dass falsche Positivmeldungen als echte Schwachstellen markiert werden, aber ich kann nicht wissen, ob das wirklich hilft, und hoffe nur, dass es nützlich war; ich habe noch nicht ausreichend evaluiert, ob das wirksam ist, also ist es weder Wissenschaft noch Engineering, ich werde die Auswertung später teilen." Das entspricht meinem eigenen Ablauf bei der Prompt-Entwicklung sehr stark.

• Ich habe den Eindruck, dass dies vielleicht der passendste Anwendungsfall für LLMs überhaupt ist: die automatische Schwachstellenerkennung.
  Theoretisch könnte man den gesamten Prozess automatisieren und das LLM wie einen hochentwickelten Fuzzer behandeln, der Ziele ständig in einer VM laufen lässt und bei erkannten Anomalien auf mögliche echte Schwachstellen schließt.
  (Dabei sollte man bedenken, dass viele frühe Exploits zunächst nur Maschinen zum Absturz bringen oder Crashes auslösen und später verfeinert werden.)
  Diese Art des LLM-Einsatzes wirkt einerseits sehr sinnvoll, deutet andererseits aber auch darauf hin, dass dadurch nichts grundlegend Neues oder Entscheidendes sichtbar wird, nur weil wir solche Tests nun durchführen können.

• Ich lasse hier einen YouTube-Link zu meinem Vortrag über automatisiertes Targeting von zk-Bugs (im Zusammenhang mit Zero-Knowledge-Proofs).

  • Hier noch einmal der bereinigte Link zum obigen YouTube-Video ohne Tracking-Parameter.
    Die zusätzlichen Parameter dienen wohl nur der Linkverfolgung.

• Ich hoffe wirklich, dass das nicht so endet wie die ständigen Probleme rund um curl.
  Zum relevanten Kontext siehe Daniel Stenbergs Beitrag.

• Soweit ich weiß, ist ksmbd als SMB-Server im Kernel-Space bekannt, der leichtergewichtig und leistungsfähiger als ein traditioneller Samba-Server sein soll.
  F1: Wer setzt ksmbd tatsächlich in Produktionsumgebungen ein?
  F2: Warum setzt man es ein?

  • 1. Ich denke, typische Nutzer sind Leute, die auf Solaris oder Windows integrierte SMB-Server im Kernel nutzen.

2. Samba ist im Vergleich leistungsmäßig deutlich schwächer, deshalb betreiben viele Leute selbst 2025 noch Windows als Filesharing-Server.
   Weiß jemand, ob das wie unter Windows native ACL-Unterstützung bietet?
   (Das war meines Wissens der letzte Grund, Solaris weiterzubetreiben; ich glaube, dort wird es über ZFS unterstützt.)
   Samba steckt weiterhin in einer anachronistischen Struktur fest, etwa bei der Synchronisierung von Unix-UIDs/GIDs und dem Sicherheitsmodell.
   Gleichzeitig gab es bei SMB-Servern im Kernel auf Windows schon tatsächlich gravierende Remote-Root-Schwachstellen, daher muss man die Trade-offs klar sehen.

• Der Grund sind Lizenzfragen.
  Samba steht unter GPLv3, Linux kann aber nur GPLv2 verwenden.

• Ich vermute, man nutzt es schlicht deshalb, weil es leichtergewichtig und performanter ist.

• Vermutlich aus einem ähnlichen Grund, aus dem man kmod-trelay statt relayd verwendet.

• Ich denke, dass sich die kurzfristig größte Herausforderung für LLMs – das Alignment-Problem – eher bei solcher Schwachstellenautomatisierung zeigt.
  Ich habe kürzlich mit fast keinem Aufwand durch ein LLM eine wirklich ernste Sicherheitslücke in einem Nischenserver gefunden, den ich gelegentlich nutze.
  Wenn dieser Markt automatisiert wird, könnten in einer Vielzahl von Long-Tail-Softwareprojekten plötzlich massenhaft gravierende Probleme auftauchen, die früher keinen manuellen Angriff wert gewesen wären.

  • Umgekehrt erlaubt uns dieser technische Fortschritt auch, unsere eigenen Codebasen automatisch aus einer „gegnerischen Perspektive“ zu analysieren.
    So hätten wir die Chance, Schwachstellen proaktiv zu patchen, die sonst erst von Forschern entdeckt und dann angegriffen würden.
    Deshalb scheint mir die Bezeichnung Alignment-Problem hier nicht ganz passend.

  • Auch Angreifer können Schwachstellen per Automatisierung finden, aber Verteidiger können dieselbe Fähigkeit ebenfalls nutzen.
    Man könnte solche Abwehrmechanismen auch in Commit-Freigaben oder bei jedem Build automatisiert einbinden.