OpenAI-Pipeline reproduziert 1.724 Linux-Kernel-Schwachstellen und baut 948 Root-Exploits

Von Einzeluntersuchungen zum systematischen Prozess

Sicherheitsforschung, die früher für jeden einzelnen Fund eine eigene, langwierige Untersuchung erforderte, lässt sich laut OpenAI zunehmend als systematischer Prozess betreiben. Das Unternehmen argumentiert, die Suche nach Schwachstellen lasse sich immer leichter skalieren, während Priorisierung und Validierung operative Engpässe blieben.

Die neue Arbeit baut auf einer Ankündigung vom Juni im Rahmen von OpenAIs Initiative Patch the Planet auf. Damals hatte GPT-5.5 Cyber Schwachstellen im Linux-Kernel identifiziert und 24 Exploits für lokale Rechteausweitung entwickelt, um sie zu validieren und zu melden. Inzwischen hat OpenAI diese Arbeit zu einer Pipeline ausgebaut, die Schwachstellensuche, dynamische Validierung, Bewertung der Ausnutzbarkeit und Patch-Erzeugung umfasst. Menschliche Forscher prüften die Ergebnisse und meldeten die Schwachstellen zusammen mit Patches. Auf Anraten der Linux-Kernel-Community begann OpenAI mit kritischen Schwachstellen und arbeitet mit den Partnern von Patch the Planet an weiteren Meldungen und Patches.

OpenAI wählte den Linux-Kernel, weil er Android-Geräten, Cloud-Infrastruktur und Supercomputern zugrunde liegt und mehr als 40 Millionen Codezeilen umfasst. Systemaufrufe, Netzwerk, Dateisysteme und Gerätetreiber bilden eine breite Angriffsfläche.

Fünf Stufen, am Ende der Mensch

Der Prototyp besteht aus fünf Stufen: Schwachstellensuche, dynamische Validierung, Bewertung der Ausnutzbarkeit, Patch-Erzeugung und menschliche Prüfung. Am Ende bündelt das System eine Ursachenanalyse, einen minimalen abstürzenden Proof of Concept, einen Patch-Kandidaten und einen vollständigen Exploit, damit Forscher den Schweregrad beurteilen und Korrekturen an die Upstream-Entwickler weitergeben können.

Die Suche beginnt mit Scout-Agenten, die Ordner und Dateien durchlesen und Prüfziele danach auswählen, ob sie für Nutzer mit niedrigen Rechten erreichbar und sicherheitsrelevant sind. Sie identifizierten 5.034 Prüfziele, etwa 2,8 Millionen Codezeilen oder rund 7 % der Kernel-Codebasis, bei Kosten von 3.426 US-Dollar an API-Guthaben. Anschließend untersuchten Analyst-Agenten jedes Ziel mit einem Ablauf, der dem Codex-Security-Plugin ähnelt. Innerhalb von 12 Stunden lieferten sie nach der Deduplizierung 2.308 mögliche Funde, bei Kosten von 316.549 US-Dollar.

Validierung: 1.724 reproduzierte Bugs

OpenAI betont, dass ein möglicher Fund noch keine validierte Schwachstelle ist. Der Triage-Agent erzeugte für jeden Kandidaten einen Proof of Concept und führte ihn in einer isolierten virtuellen Maschine mit einem Linux-Kernel mit Kernel Address Sanitizer (KASAN) aus. Der Agent verfeinerte den Proof of Concept so lange, bis er das gemeldete Verhalten reproduzierte oder keine Wege mehr fand, es auszulösen.

Innerhalb von 30 Stunden reproduzierte das System 1.724 Schwachstellen, etwa 74,7 % der 2.308 Kandidaten. OpenAI zeigt sich beeindruckt von der Treffsicherheit der Analyst-Agenten, da eine rein statische Codeprüfung häufig Fehlalarme produziert. Die meisten übrigen Funde erforderten entweder erhöhte Rechte oder ließen sich im vorgegebenen Zeitbudget nicht reproduzieren, etwa wegen schwieriger Race Conditions, spezieller Auslösebedingungen oder aufwendiger Validierung. Nur 3,1 % gingen auf eine fehlerhafte Analyse des Modells zurück, bei der der gemeldete Bug eine unmögliche Bedingung voraussetzte. Die Validierung kostete 73.330 US-Dollar an API-Guthaben.

OpenAI weist außerdem darauf hin, dass die Validierung eines echten und eines falschen Treffers ähnlich viel kostete und dass die Erzeugung eines Proof of Concept teurer war als eine Empfehlung allein auf Basis statischer Analyse. Fehlalarme früher auszusortieren, macht den Prozess daher deutlich kosteneffizienter.

Ausnutzbarkeit: von 1.724 Bugs zu 948 Root-Pfaden

Weil die Validierung zeigt, dass ein Bug real ist, nicht aber, wie dringlich er ist, prüfte ein Screening-Agent jeden Bericht, das Absturzprotokoll und den relevanten Quellcode statisch. Er arbeitete bewusst großzügig. Dadurch schrumpfte die Menge auf 313 Kandidaten für Informationslecks und 1.238 Kandidaten für lokale Rechteausweitung.

ExploitDev-Agenten testeten diese anschließend in isolierten virtuellen Maschinen, die mit den Schutzmechanismen einer gängigen Linux-Distribution konfiguriert waren, darunter SMEP, SMAP, KASLR und HARDENED_USERCOPY. Laut OpenAI vermeidet das unrealistische Bewertungen, die auf abgeschalteten Schutzmaßnahmen beruhen. Die Agenten erzeugten 291 Proofs of Concept für Informationslecks und 1.169 funktionierende Exploits für lokale Rechteausweitung. Nach einer Variantenanalyse entwickelte OpenAI 948 unterschiedliche Patches für die Schwachstellen hinter diesen Exploits und verwendet diese Zahl als Anzahl der einzigartigen lokalen Rechteausweitungen. Erfolgreiche Exploits kosteten in der Entwicklung durchschnittlich 359 US-Dollar an Guthaben.

Was das für Verteidiger bedeutet

OpenAI beschreibt die Mission seines Cyber-Teams so: die Software abzusichern, auf die die Welt angewiesen ist. Verteidigern soll geholfen werden, Schwachstellen zu finden und zu beheben, Angreifern Gelegenheiten zu nehmen und ihre Kosten für das Ausnutzen von Software zu erhöhen. Das Unternehmen nennt die API-Kosten jeder Stufe, damit andere Forscher abschätzen können, welche Ressourcen nötig sind, um die Arbeit nachzuvollziehen und auszubauen.

Zugleich schränkt es ein, dass sich die Forschung auf Methodik und die Messung der Modellfähigkeiten konzentrierte, nicht auf die Kosten. Aus seiner Sicht könnte ausreichendes Harness Engineering die Kosten jeder Stufe spürbar senken, die veröffentlichten Zahlen seien daher eher eine Obergrenze. Das eigene Fazit des Unternehmens lautet: Die schwierige Aufgabe sei in diesem Maßstab nicht mehr, mögliche Bugs zu finden, sondern zu bestimmen, welche sich reproduzieren lassen, welche Sicherheitsgrenze sie überschreiten und welche zuerst die Aufmerksamkeit der Maintainer verdienen.