Remote 0-Day in Linux-SMB-Implementierung mit o3 entdeckt
(sean.heelan.io)- Bei einem Audit von ksmbd, der SMB3-Server-Implementierung im Linux-Kernel, wurde allein mit der OpenAI-o3 API die Remote-Use-after-free-Schwachstelle CVE-2025-37899 gefunden; es kamen keine separaten Agent-Frameworks oder Tools zum Einsatz
- Die Schwachstelle besteht darin, dass während der Verarbeitung des SMB-
logoff-Befehls ein anderer Thread weiter auf das freigegebenesess->userzugreifen kann; sichtbar wird sie nur, wenn man gleichzeitige Verbindungen und gemeinsam genutzten Sitzungszustand zusammen betrachtet - In einem Benchmark auf Basis der manuell gefundenen CVE-2025-37778 fand o3 die Schwachstelle in 8 von 100 Durchläufen; Claude Sonnet 3.7 schaffte 3 Treffer, Claude Sonnet 3.5 keinen
- Unter Bedingungen mit 12k LoC / 100k Eingabetokens, bei denen die Eingabe auf alle SMB-Befehlshandler und Code zur Verbindungsverarbeitung erweitert wurde, sank die Trefferquote für die bekannte Schwachstelle auf 1 von 100, doch aus demselben Ergebnis ging die neue Schwachstelle CVE-2025-37899 hervor
- False Positives und sinnlose Ausgaben sind weiterhin häufig, aber die Wahrscheinlichkeit, eine richtige Antwort zu erhalten, ist hoch genug geworden, dass sich menschliche Prüfung und Verifikation in realer Schwachstellenforschung lohnen
Experiment: ksmbd-Schwachstelle mit o3 finden
- Ziel des Audits war ksmbd, die Implementierung von SMB3-Protokoll-Filesharing im Linux-Kernel-Space
- Das OpenAI-o3-Modell wurde über die
o3 APIaufgerufen; es gab kein zusätzliches Scaffolding, kein Agent-Framework und keine Tool-Nutzung - Die gefundene Schwachstelle ist CVE-2025-37899; der Fix findet sich in einem Linux-Kernel-Commit
- Das Kernproblem ist ein Use-after-free im Handler für den SMB-
logoff-Befehl: Ein Objekt ohne Referenzzählung wird freigegeben, obwohl es weiterhin von einem anderen Thread erreichbar ist - Um diese Schwachstelle zu finden, muss man gleichzeitige Verbindungen zum Server und Objekte verstehen, die unter bestimmten Umständen gemeinsam genutzt werden
- Enthalten ist die Einschätzung, dass dies unter den öffentlich diskutierten Fällen offenbar der erste ist, in dem ein LLM eine Schwachstelle dieser Art gefunden hat
Referenzschwachstelle CVE-2025-37778
- Zunächst wurde die manuell gefundene CVE-2025-37778 als Benchmark zur Bewertung der o3-Leistung verwendet
- Diese Schwachstelle ist ein Use-after-free im Kerberos-Authentifizierungspfad bei der Verarbeitung einer
session setup-Anfrage eines Remote-Clients krb5_authenticategibtsess->userfrei, wennsess->state == SMB2_SESSION_VALIDgilt- Der nachfolgende Code stützt sich auf die Annahme, dass
ksmbd_krb5_authenticateden Wert neu und gültig initialisiert oder dasssess->usernach der Rückgabe von-EINVALnicht mehr verwendet wird - Tatsächlich kann man erreichen, dass
ksmbd_krb5_authenticatesess->usernicht neu initialisiert, und selbst wennkrb5_authenticate-EINVALzurückgibt, ist ein Zugriff aufsess->usermöglich
Benchmark-Aufbau und Prompt
- CVE-2025-37778 wurde als Benchmark genutzt, weil sie auf der Remote-Angriffsfläche liegt und man dafür sowohl das Herbeiführen der Bedingung
sess->state == SMB2_SESSION_VALIDals auch einen Pfad ohne Reinitialisierung und einen Zugriffspfad nach der Freigabe beurteilen muss - Der minimale Code, der nötig ist, um den Schwachstellenpfad zu beschreiben, wurde auf etwa 3,3k LoC berechnet
- Die Experiment-Eingabe enthielt den
session setup-Befehlshandler und die Funktionen, die dieser Handler bis zu einer Aufruftiefe von 3 aufruft - Ebenfalls enthalten waren Paketerfassung, Request-Parsing, Auswahl des Befehlshandlers und Code zum Aufräumen der Verbindung nach Abschluss des Handlers, um Spekulationen über die Initialisierung von Datenstrukturen zu reduzieren
- Die finale Eingabe umfasste etwa 3,3k LoC / 27k Tokens; die analysierte Datei ist als session_setup_code.prompt veröffentlicht
- Der Prompt enthielt folgende Bedingungen
- Anweisung, Use-after-free-Schwachstellen zu finden
- ksmbds Rolle, Architektur und Threat Model auf hoher Ebene
- Starke Präferenz, eher nichts zu melden als False Positives zu berichten
- Die vollständige Prompt-Datei befindet sich im Repository o3_finds_cve-2025-37899
- Für die Ausführung wurde Simon Willisons Tool
llmverwendet
Ergebnisse des CVE-2025-37778-Benchmarks
- Das Experiment-Harness führte dieselbe Anfrage 100-mal aus und speicherte die Ergebnisse
- o3 fand CVE-2025-37778 in 8 von 100 Durchläufen
- In 66 von 100 Fällen entschied es, dass kein Bug vorliegt, was False Negatives ergab
- Die übrigen 28 Fälle waren False Positives
- Die Vergleichsergebnisse lauteten wie folgt
- Claude Sonnet 3.7: 3 Funde in 100 Durchläufen
- Claude Sonnet 3.5: 0 Funde in 100 Durchläufen
- In diesem Benchmark zeigte o3 eine 2- bis 3-fache Verbesserung gegenüber Claude Sonnet 3.7
- Beispielberichte sind als o3-Ergebnis und Sonnet-3.7-Ergebnis veröffentlicht
- Die o3-Ausgabe liest sich wegen Struktur und Fokus wie ein von Menschen geschriebener komprimierter Bugreport, kann aber gelegentlich zu kurz und damit weniger klar sein
- Die Sonnet-3.7-Ausgabe erscheint eher in Form eines Gedankengangs oder Arbeitsprotokolls
Experiment mit allen Befehlshandlern
- Im nächsten Experiment wurde o3 nicht nur der
session setup-Handler, sondern der Code aller SMB-Befehlshandler bereitgestellt - Die Befehlshandler befinden sich in
smb2pdu.c; die Datei ist etwa 9k LoC groß - Alle Handler, Verbindungsaufbau- und Aufräumcode sowie die Dispatch-Routinen für Befehlshandler zusammen ergaben etwa 12k LoC / 100k Eingabetokens
- Auch unter diesen Bedingungen wurde das Experiment 100-mal ausgeführt
- o3 fand die bekannte Kerberos-Authentifizierungsschwachstelle CVE-2025-37778 nur 1-mal von 100; mit der steigenden Zahl an Eingabetokens war ein deutlicher Leistungsabfall zu sehen
- In derselben Ergebnismenge wurde ein Bericht zu einer zuvor unbekannten neuen Schwachstelle gefunden: CVE-2025-37899
Verwundbarer Pfad von CVE-2025-37899
- Auch die neue Schwachstelle hängt mit der Freigabe von
sess->userzusammen, tritt diesmal aber im Session-Logoff-Handler auf smb2_session_logoffarbeitet in folgender Reihenfolge- Aufruf von
ksmbd_close_session_fds(work) - Aufruf von
ksmbd_conn_wait_idle(conn) - Setzen des Sitzungsstatus auf
SMB2_SESSION_EXPIRED - Falls
sess->userexistiert, Freigabe mitksmbd_free_user(sess->user)und Setzen vonsess->user = NULL
- Aufruf von
- Das Schwachstellenszenario im o3-Bericht lautet wie folgt
- Ab SMB 3.0 wird ein zweiter Transport an eine bestehende Sitzung gebunden und
conn->binding == truewird gesetzt - Worker-A verarbeitet auf einer anderen Verbindung C2 eine normale Anfrage wie WRITE
smb2_check_user_session()speichert den bestehenden Pointer aufstruct ksmbd_sessioninwork->sessund erhöht den Sitzungs-Referenzzähler, hält aber keine separate Referenz aufsess->user- Worker-B verarbeitet auf der ersten Verbindung C1 ein SMB2 LOGOFF für dieselbe Sitzung und führt
smb2_session_logoff()aus ksmbd_conn_wait_idle(conn)wartet nur auf laufende Requests dieser Verbindung, nicht auch auf Requests anderer Verbindungen, die dieselbe Sitzung verwenden- Worker-A läuft weiter und kann Zugriffe wie
user_guest(sess->user),ksmbd_compare_user(sess->user, …)odersess->user->uidausführen
- Ab SMB 3.0 wird ein zweiter Transport an eine bestehende Sitzung gebunden und
- Je nach Timing wird daraus ein Use-after-free auf ein freigegebenes slab-Objekt oder, wenn nach
sess->user = NULLgelesen wird, eine NULL-Dereferenzierung mit DoS-Folge
Falscher Fix und Wert der o3-Ergebnisse
- Der ursprünglich für CVE-2025-37778 vorgeschlagene Fix bestand darin, nach
ksmbd_free_user(sess->user)einsess->user = NULLhinzuzufügen - Nach der Lektüre des CVE-2025-37899-Berichts wurde klar, dass dieser Fix unzureichend ist
- Der
logoff-Handler führt bereitssess->user = NULLaus, bleibt aber verwundbar, weil das SMB-Protokoll zwei unterschiedliche Verbindungen an dieselbe Sitzung binden kann - Auch im Kerberos-Authentifizierungspfad kann in dem kurzen Fenster direkt nach Freigabe von
sess->userund vor dem Setzen auf NULL ein anderer Thread darauf zugreifen - Einige o3-Berichte machten denselben Fehler, andere erkannten jedoch, dass
sess->user = NULLallein wegen der möglichen Sitzungsbindung nicht ausreicht - Eine Einschränkung ist, dass wegen des hohen Verhältnisses von True Positives zu False Positives unklar ist, ob alle Berichte ausreichend sorgfältig geprüft wurden
Praktische Einordnung in der Schwachstellenforschung
- LLMs stehen in puncto Kreativität, Flexibilität und Allgemeinheit näher an menschlichen Code-Auditoren als klassische Programmanalyseverfahren
- Als Vergleichspunkte werden symbolic execution, abstract interpretation und fuzzing genannt
- Seit GPT-4 bestand zwar Potenzial für LLMs in der Schwachstellenforschung, in realen Problemen blieben die Ergebnisse aber hinter den Erwartungen zurück
- o3 funktioniert bei Code-Reasoning, Frage-Antwort-Aufgaben, Programmierung und Problemlösung gut genug, um die Leistung echter Schwachstellenforscher zu steigern
- Es ist weiterhin nicht perfekt und erzeugt mit hoher Wahrscheinlichkeit sinnlose Ergebnisse, die Nutzer frustrieren können
- Neu ist die Einschätzung, dass die Wahrscheinlichkeit, eine richtige Antwort zu erhalten, erstmals hoch genug ist, um es auf reale Probleme anzuwenden
1 Kommentare
Meinungen auf Hacker News
Es ist nur ein kleiner Punkt, aber die Art, wie der Autor sein Projekt strukturiert, wirkt nützlich. System-Prompt, Hintergrundinformationen und ergänzende Anweisungen werden jeweils als
.prompt-Dateien angelegt [1] und mitllmausgeführt.Das zeigt, dass gute LLM-Nutzung, wie andere Engineering-Werkzeuge auch, systematisches, spezifikationsorientiertes Engineering-Denken erfordert, das Designbeschränkungen ausgewogen berücksichtigt.
[1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899
Das wirkt alles wie Beschwörungen nach Bauchgefühl. Formulierungen wie „Sie sind Experte für das Auffinden von Schwachstellen“, „Melden Sie nur echte Schwachstellen ohne False Positives“ oder die Strukturierung mit Fake-HTML-Tags, weil das Modell das irgendwie zu mögen scheint. Ich sehe nicht, wo hier das Engineering ist.
Solche Prompts sollte man nicht Anweisungen nennen, sondern Hinweise. Alle heutigen LLMs ignorieren den Prompt, wenn er mit ihrem einzigen übergeordneten Ziel kollidiert: eine Antwort zu liefern, egal ob sie wahr ist oder nicht.
Ein LLM um Hilfe beim Schreiben von Prompts zu bitten, ist ebenfalls überraschend effektiv. Auch meine Prompt-Bausteine habe ich alle mit LLM-Unterstützung entworfen.
Persönlich lege ich alles in org-mode-Dateien ab und kopiere es bei Bedarf in eine ChatGPT-Unterhaltung. Ich bevorzuge eher „diskussionsartige“ Interaktionen, aber der Ansatz ist derselbe.
Im Artikel heißt es, das Signal-Rausch-Verhältnis liege ungefähr bei 1:50. Der Autor kennt diese Codebasis sehr gut und ist daher in einer guten Position, das Signal im Rauschen herauszufiltern.
Die eigentlichen Fortschritte werden wohl daraus entstehen, diesen Teil zu automatisieren; ich werde das weiter beobachten.
Immer wenn ein neues Frontier-LLM erscheint, lasse ich diese Interviewaufgaben darauf laufen, ausgenommen Modelle, die Eingaben als Trainingsdaten verwenden. Ich war überrascht, dass der Anteil der Antworten, die beim ersten Versuch funktionieren, ziemlich konstant bei etwa 1:10 bleibt, und dass man oft mehr als 10 Runden nachhaken muss, damit es seine eigenen Fehler findet.
Deshalb erscheint mir ein solches Signal-Rausch-Verhältnis bei einem schwierigeren Thema plausibel.
Die Ergebnisse streuen ziemlich stark, und ich werde sie vollständig in einem kommenden Konferenzvortrag veröffentlichen; darauf kann man sich freuen. Das wird den aktuellen Stand dieses Bereichs recht gut zeigen.
Edit: Die Formulierung war verwirrend.
Ein solches LLM wäre vielleicht eine synthetische Version von jemandem, der jahrelang in der Codebasis gearbeitet und all ihre Eigenheiten gelernt hat.
In lange Kontexte passt wirklich viel hinein, aber manche Codebasen haben schon allein als Code 200.000 Tokens, daher bin ich mir nicht sicher.
Das gilt besonders bei einem binären Turnier wie RAInk, das vor ein paar Wochen hier auftauchte, und auch Ansätze mit Konsens zwischen verschiedenen LLMs sind möglich. Ich bin überrascht, dass hier nicht Gemini 2.5 PRO verwendet wurde; meiner Erfahrung nach ist es für diese Art von Aufgaben das stärkste LLM.
Der interessanteste und wichtigste Teil des Artikels war für mich, dass der Autor die Schwachstellensuche 100-mal pro Modell ausgeführt hat.
Das ist deutlich mehr Rechenaufwand, als ich für die meisten Probleme eingeplant hätte, die ich bisher mit großen Sprachmodellen ausprobiert habe; vielleicht muss man die Modelle aber einfach immer weiter laufen lassen.
Ich weiß nicht, wie die Cybersicherheitswelt aussehen wird, wenn Inferenzkosten gegen null gehen, aber sie wird ein ganz anderer Raum sein als heute.
Es ist eher so, als würde man Luxus und Verschwendung feiern. Trotz globalem Klimawandel verbrennen wir weiter Ressourcen für Belanglosigkeiten, als wären wir in den 1950ern.
Entweder hatte ich sehr viel Glück, oder Gemini 2.5 PRO findet diese Schwachstelle wie vermutet leichter. Die Erfolgsquote war hoch, sodass es reichte, den folgenden Prompt ein paar Mal laufen zu lassen: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...
In letzter Zeit wiederholt sich dieses Muster immer häufiger.
Wenn es ein Problem mit einer klaren Definition und einer Bewertungsfunktion gibt, lässt man das LLM den Lösungsraum verkleinern. LLMs sind sehr stark darin, Muster zu rekonstruieren, und wenn die Lösung einem bereits bekannten Muster ähnelt, kann das gut funktionieren.
In diesem Fall ist das Problem eine bestimmte Art von Sicherheitslücke, und der Evaluator ist ein Experte. Der Maßstab ist anders, aber vom Ansatz her ähnelt es jüngeren Versuchen, LLMs für genetische Optimierung einzusetzen.
„Mathematical discoveries from program search with large language models“ ist ebenfalls eine interessante Lektüre; ich meine, das war früher auch schon auf HN.
https://www.nature.com/articles/s41586-023-06924-6
Nur aus diesem Experiment zu schließen, dass LLMs über Code schlussfolgern, halte ich persönlich allerdings für etwas gewagt.
Ich hoffe, dass das echt ist und nicht so etwas wie das, was ständig bei curl passiert.
[1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
Bei der Behauptung, das sei die erste mit einem LLM gefundene Schwachstelle, bin ich mir nicht sicher. Zum Beispiel hat OSS-Fuzz [0] per Fuzzing einige gefunden, und Big Sleep hat auch mit einem agentenbasierten Ansatz welche gefunden [1].
[0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
[1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...
Im Artikel hieß es: „Um die Schwachstelle zu verstehen, muss man gleichzeitige Verbindungen zum Server nachvollziehen und verstehen, wie mehrere Objekte in bestimmten Situationen geteilt werden. o3 hat das verstanden und die Stelle gefunden, an der ein bestimmtes, nicht referenzgezähltes Objekt freigegeben wird, während es in einem anderen Thread weiterhin zugreifbar ist. Soweit ich weiß, ist dies die erste öffentliche Diskussion darüber, dass ein LLM eine Schwachstelle dieser Art gefunden hat.“
Was ich sagen wollte: Soweit ich weiß, ist dies die erste öffentliche Dokumentation, in der ein LLM genau diese Art von Bug gefunden hat – also einen Bug, der aus einer nicht trivialen Menge an Code und gleichzeitigem Zugriff auf gemeinsam genutzte Ressourcen entsteht. Zumindest für mich ist das ein interessantes Zeichen für den Fortschritt von LLMs.
Wenn man den Wert der Entdeckung von Zero-Days bedenkt: Falls man sie mit nur ein paar Hundert API-Aufrufen zuverlässig finden kann, wird praktisch jeder Nachrichtendienst der Welt Geld hineinstecken.
Besonders dann, wenn man das Modell mit vielen Beispielen feinabstimmen kann; und ich glaube nicht, dass Anbieter wie OpenAI so etwas über eine öffentliche API ermöglichen würden.
Für Regierungsbehörden oder andere Organisationen sind solche Einschränkungen natürlich kein Problem. Sie gelten nur für alle anderen. Deshalb werden Menschen andere Modelle und Agenten verwenden, die solchen Beschränkungen nicht unterliegen.
Man kann wohl sicher davon ausgehen, dass in wichtiger Software überall viele Schwachstellen existieren. Jetzt können wir sie finden. Für Computersicherheit und Hacking beginnt eine Situation, auf die Wettrüsten-Spieltheorie zutrifft. Vermutlich kommt das schneller, als man erwartet.
Ich weiß, dass ein paar Kernel-Entwickler diesen Bug „verifiziert“ haben, aber ich frage mich, ob tatsächlich jemand einen Proof of Concept gebaut und getestet hat.
In diesem Ablauf ist das ein so zentraler Teil, aber der Proof of Concept fehlt vollständig. Ohne Proof of Concept weiß man nicht, welche Probleme unterwegs auftreten könnten, und kann daher weder Ausnutzbarkeit noch Auswirkungen beurteilen. Immerhin hat der Autor es ohne Verifikation nicht Remote Code Execution genannt.
Aber was, wenn es ein Puzzleteil gibt, das der Autor und die Entwickler übersehen haben oder von dem sie annahmen, o3 habe es berücksichtigt, das in Wirklichkeit aber außerhalb von o3s Kontext lag – und das die Schwachstelle selbst zunichtemacht?
Ich sage nicht, dass es so etwas gibt, und ich werde auch keine Zeit darauf verwenden, die Arbeit des Autors zu übernehmen. Aber dieser Bericht ist nicht vollständig verifiziert, und angesichts der Möglichkeit, dass er ein einflussreicher Blogpost im Bereich der LLM-Schwachstellenforschung wird, fühlt sich das wie ein gefährlicher Präzedenzfall an.
Persönlich finde ich, dass man bei jedem von einem Modell erzeugten Schwachstellenbericht PoC || GTFO strenger denn je anwenden sollte.
Die Sichtweise, dass o3 deutlich besser ist als frühere Modelle oder andere aktuelle Modelle, bleibt trotzdem bestehen, und auch die Methodik ist interessant. Ich verstehe den Wunsch und die Notwendigkeit, Formulierungen so zu wählen, dass Menschen auf etwas Bestimmtes aufmerksam werden. Das ist das Clickbait-Problem. Aber bitte, wir müssen es besser machen. Man sollte einen Proof of Concept bauen und die Behauptungen verifizieren, statt faul zu sein. Wenn man einen Blogpost schreibt, der beeinflussen kann, wie Schwachstellenforscher arbeiten, sollte man Verifikation fördern, nicht theoretische Annahmen. Andernfalls verbreiten falsche, aber plausibel klingende Berichte Unwissen, statt durch überprüfbare und belegte Reports das Systemverständnis zu vertiefen.
Es gibt eine schöne kleine Passage, die perfekt einfängt, wie die meisten meiner Prompt-Entwicklungssessions ablaufen