Tausend Wege weniger zu Root-Rechten

Sicherheitsforschung, die früher für jeden Befund eine eigene, langwierige Untersuchung erforderte, lässt sich zunehmend als systematischer Prozess durchführen. Dieser Bericht stellt eines unserer Projekte in diesem Bereich vor.

Die Schwachstellensuche lässt sich immer leichter skalieren, doch Priorisierung und Validierung bleiben operative Engpässe. Wir haben einen Prototyp entwickelt, der in einer kontrollierten Forschungsumgebung nach Sicherheitslücken im Linux-Kernel sucht. Unser Prototyp identifizierte und analysierte 2.308 potenzielle Befunde im Linux-Kernel, reproduzierte dynamisch 1.724 Schwachstellen und erzeugte 948 Exploits zur lokalen Rechteausweitung (LPE). Diese könnten lokalen Konten ohne besondere Berechtigungen Root-Zugriff verschaffen.

Anhand dieser Nachweise priorisierten wir die zu meldenden Schwachstellen und entwickelten Patch-Vorschläge zur Prüfung durch die Maintainer-Teams. Auf Empfehlung der Linux-Kernel-Community begannen wir mit kritischen Schwachstellen. Gemeinsam mit den Partnerorganisationen von Patch the Planet arbeiten wir an weiteren Berichten und Patches.

Im Juni berichteten wir im Rahmen unserer Initiative Patch the Planet, dass GPT‑5.5 Cyber Schwachstellen im Linux-Kernel identifiziert und 24 Exploits zur lokalen Rechteausweitung entwickelt hatte, um diese zu validieren und zu melden. Diese Arbeit haben wir zu einer Pipeline ausgebaut, die auf einem kommenden Cybermodell basiert. Sie umfasst die Schwachstellensuche, dynamische Validierung, Bewertung der Ausnutzbarkeit und Patch-Erstellung. Nach Abschluss prüften Forschende die Ergebnisse und meldeten die gefundenen Schwachstellen zusammen mit den Patches.

Der Linux-Kernel bildet die Grundlage für Android-Geräte, Cloud-Infrastruktur, Supercomputer und weitere Systeme, die Milliarden Menschen nutzen. Mit mehr als 40 Millionen Codezeilen bietet der Kernel über Systemaufrufe, Netzwerkfunktionen, Dateisysteme und Gerätetreiber eine große Angriffsfläche. Wir wählten Linux, um zu untersuchen, wie effektiv Frontier-Modelle in einer Codebasis dieser Größe und Bedeutung Schwachstellen finden und deren Sicherheitsauswirkungen nachweisen können.

Die erste Phase der Schwachstellensuche lieferte Tausende potenzielle Befunde. Das waren zu viele, um sie in der Sicherheitsforschung manuell zu prüfen und einzuordnen. Die operative Herausforderung unserer Pipeline lag nicht im Finden von Schwachstellen. Entscheidend war vielmehr festzustellen, welche Befunde sich reproduzieren ließen, welche Sicherheitsgrenze sie überschritten und welchen sich die Maintainer-Teams zuerst widmen sollten.

Das Cyberteam von OpenAI hat die Aufgabe, die Software abzusichern, auf die sich Menschen weltweit verlassen. Wir geben die API-Kosten jeder Phase an, damit Forschende abschätzen können, welche Ressourcen nötig sind, um diese Arbeit zu reproduzieren und weiterzuführen. Diese Kosten beziehen sich auf die Modelle, Zielkonfigurationen und den Workflow dieser Untersuchung. Unser übergeordnetes Ziel ist es, Sicherheitsverantwortliche beim Finden und Beheben von Schwachstellen zu unterstützen. So wollen wir Angriffsmöglichkeiten reduzieren und die Kosten für die Ausnutzung von Software erhöhen.

Zu beachten ist außerdem, dass der Schwerpunkt dieser Forschung auf der Methodik und der Messung der Modellfähigkeiten lag, nicht auf den Kosten. Wir erwarten, dass sich die Kosten in jeder Phase durch eine ausreichende Optimierung des Harnesses deutlich senken ließen. Die angegebenen Kosten sind daher eher als Obergrenze zu verstehen.

Unser Prototyp zur Schwachstellenforschung ist eine fünfstufige Pipeline, deren Kern ein kommendes Cybermodell bildet:

• Schwachstellensuche: Agenten identifizieren sicherheitsrelevante Teile der Codebasis und scannen sie nach potenziellen Befunden.

• Dynamische Validierung: Agenten versuchen, jeden potenziellen Befund in einer isolierten Umgebung zu reproduzieren, und sichern Laufzeitnachweise. Dieser Schritt liefert die reproduzierten und validierten Schwachstellen.

• Bewertung der Ausnutzbarkeit: Agenten testen, ob validierte Schwachstellen die Offenlegung von Informationen oder eine lokale Rechteausweitung ermöglichen könnten.

• Patch-Erstellung: Agenten erstellen Patches, die die jeweils identifizierte Schwachstelle beheben.

• Prüfung durch Menschen: Fachleute aus der Sicherheitsforschung prüfen den Exploit, den Patch und den vorgeschlagenen Schweregrad, bevor sie die Ergebnisse an die Maintainer-Teams melden.

Am Ende der Pipeline bündelt das System eine Ursachenanalyse, einen minimalen Proof of Concept, der einen Absturz auslöst, einen Patch-Vorschlag und einen vollständigen Exploit. Damit unterstützt es Forschende dabei, den Schweregrad der Schwachstelle zu bewerten und die Korrekturen in das Upstream-Projekt einzubringen.

Nicht jede Codezeile im Linux-Kernel ist sicherheitsrelevant. Unsere Pipeline setzte ein Team von Scout-Agenten ein, um besonders relevante Prüfziele zu identifizieren. Diese wurden anschließend an Analyst-Agenten zur Schwachstellenanalyse übergeben.

Scout-Agenten lesen sämtliche Ordner und Dateien durch. Anhand der Erreichbarkeit für Konten mit geringen Rechten und der Sicherheitsrelevanz entscheiden sie, welche Ziele geprüft werden sollen.

In dieser Phase wurden 5.034 Prüfziele mit etwa 2,8 Millionen Codezeilen identifiziert. Das entspricht rund 7 % der gesamten Codebasis des Linux-Kernels und senkt die Kosten der Sicherheitsprüfung gegenüber einer vollständigen Codeanalyse erheblich. Dieser Schritt kostete 3.426 USD an API-Credits.

Als Nächstes analysierten Analyst-Agenten jedes Prüfziel und erstellten potenzielle Befunde. Ihr Workflow ähnelte dem des Plugins Codex Security⁠(wird in einem neuen Fenster geöffnet). Im Wesentlichen lesen die Analyst-Agenten den Code des zugewiesenen Prüfziels, um seine Funktionsweise zu verstehen, das Bedrohungsmodell zu bestimmen und nach Schwachstellen zu suchen.

Innerhalb von 12 Stunden lieferten die Analyst-Agenten nach Entfernung von Duplikaten 2.308 potenzielle Befunde. Diese Phase kostete 316.549 USD an API-Credits.

Ein potenzieller Befund ist noch keine validierte Schwachstelle. Bei dieser Größenordnung ist es für unser Forschungsteam nicht praktikabel, jeden Bericht manuell zu untersuchen.

Wir konzentrierten uns daher auf die Validierung von Befunden, die a) mit geringen Rechten erreichbar waren, b) keine besonderen Berechtigungen erforderten und c) messbare Nachweise für Speicherbeschädigungen lieferten.

Für jeden potenziellen Befund erzeugte ein Triage-Agent einen Proof of Concept und führte ihn in einer isolierten virtuellen Maschine aus, deren Linux-Kernel den Kernel Address Sanitizer (KASAN) nutzte. Der Agent beobachtete sowohl die Programmausgabe als auch die Systemkonsole. Anschließend überarbeitete er den Proof of Concept schrittweise, bis dieser das gemeldete Verhalten reproduzierte oder alle Möglichkeiten zur Auslösung ausgeschöpft waren.

Innerhalb von 30 Stunden reproduzierte unser System 1.724 Schwachstellen, rund 74,7 % der 2.308 potenziellen Befunde. Eine rein statische Codeprüfung kann zu Fehlalarmen führen. Daher beeindruckten uns die Genauigkeit der Analyst-Agenten und die Effektivität der Triage-Agenten: Für fast drei Viertel der potenziellen Befunde erstellten sie autonom funktionierende Proofs of Concept.

Die meisten übrigen Befunde erforderten entweder erhöhte Rechte oder ließen sich innerhalb des Zeitbudgets nicht reproduzieren. Gründe dafür waren schwierige Race Conditions, spezifische Auslösebedingungen (z. B. eine erforderliche fehlgeschlagene Speicherzuweisung an einer bestimmten Codezeile) oder eine zeitaufwendige Validierung (z. B. ein Überlauf des Referenzzählers). Nur 3,1 % beruhten auf einer fehlerhaften Analyse des Modells, bei der die gemeldete Schwachstelle eine unmögliche Bedingung voraussetzte.

Die Validierungsphase kostete insgesamt 73.330 USD an API-Credits. In unserer Validierungspipeline musste ein Proof of Concept erstellt werden, um zu bestätigen, ob ein potenzieller Befund tatsächlich eine Schwachstelle war. Dieser Prozess war teurer als eine Empfehlung auf Basis rein statischer Analyse. Die Kosten eines Validierungsversuchs waren bei echten Schwachstellen und Fehlalarmen ähnlich. Werden Fehlalarme früher in der Pipeline herausgefiltert, wird der Prozess daher deutlich kosteneffizienter.

Die Validierung bestätigt, dass eine Schwachstelle tatsächlich besteht, aber nicht, wie dringend sie behoben werden sollte. Eine Schwachstelle, die eine lokale Rechteausweitung ermöglichen könnte, verdient beispielsweise höhere Priorität als eine, die nur einen lokalen Denial of Service verursachen könnte. Nach der Validierung von 1.724 Schwachstellen galt es, die Befunde mit den potenziell größten Sicherheitsauswirkungen zu identifizieren.

Ein Agent zur Vorauswahl prüfte jeden Bericht, jedes Absturzprotokoll und den relevanten Quellcode mittels statischer Analyse. Er war bewusst großzügig eingestellt, um potenziell schwerwiegende Befunde nicht auszusortieren. Zugleich filterte er Fälle ohne plausiblen Ausnutzungsweg heraus. Dadurch wurden die Ergebnisse auf 313 Kandidaten für Informationsabfluss und 1.238 Kandidaten für lokale Rechteausweitung eingegrenzt.

Agenten zur Exploit-Entwicklung (ExploitDev) testeten diese Kandidaten anschließend in isolierten virtuellen Maschinen. Darin waren die Schutzmechanismen einer Standard-Linux-Distribution aktiviert, darunter Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) und HARDENED_USERCOPY. So ließen sich unrealistische Bewertungen vermeiden, die deaktivierte Schutzmechanismen voraussetzten.

Die Agenten erzeugten 291 Proofs of Concept für Informationsabfluss und 1.169 funktionierende Exploits zur lokalen Rechteausweitung, die lokalen Konten ohne besondere Berechtigungen Root-Zugriff verschaffen könnten.

Wir führten eine Variantenanalyse durch und entwickelten 948 unterschiedliche Patches für die Schwachstellen hinter diesen Exploits. Diese Zahl verwenden wir als Gesamtzahl der unterschiedlichen LPEs. Die Entwicklung erfolgreicher Exploits kostete durchschnittlich 359 USD an Credits. Damit können Sicherheitsverantwortliche die Ausnutzbarkeit gefundener Schwachstellen vergleichsweise kostengünstig testen.

Der Agent zur Vorauswahl der Schwachstellen verursachte Kosten von 44.194 USD an API-Credits. Die Exploit-Phase kostete insgesamt 775.929 USD an API-Credits: 84.929 USD für die Bearbeitung von Kandidaten für Informationsabfluss und 691.000 USD für Kandidaten für lokale Rechteausweitung.

Im Durchschnitt war die Bearbeitung eines Kandidaten für lokale Rechteausweitung (558 USD) etwa doppelt so teuer wie die eines Kandidaten für Informationsabfluss (271 USD). Der Grund: PoCs für Informationsabfluss wurden aus der Validierungsphase übernommen und mussten weniger angepasst werden, um in einem Exploit nutzbar zu sein. Die Entwicklung eines Exploits aus einem LPE-Kandidaten erforderte dagegen viele zusätzliche Schritte: etwa die Planung der Ausnutzungsstrategie, die Identifizierung geeigneter anfälliger Objekte und die Umgehung von Schutzmaßnahmen. Außerdem stellten wir fest, dass erfolglose Ausnutzungsversuche (3.922 USD bei 69 Fällen) deutlich mehr kosteten als erfolgreiche (360 USD bei 1.169 Fällen). Verantwortlich dafür waren einige schwer ausnutzbare Schwachstellen, beispielsweise Race Conditions. Eine sinnvolle Abbruchbedingung, etwa den Versuch nach einer Stunde ohne Fortschritt zu beenden, hätte die Kosten von ExploitDev erheblich gesenkt.

Für jede validierte Schwachstelle erstellt das System auch einen Patch. Wir stellen dem Modell den relevanten Quellcode bereit und geben ihm bewährte Vorgehensweisen für die Patch-Erstellung vor: statische Prüfungen des Patches durchführen, die Entwicklungspraktiken des umliegenden Codes befolgen und anhand einer Variantenanalyse sicherstellen, dass der Patch vollständig ist.

Auf Empfehlung der Linux-Kernel-Community haben wir bereits Hunderte Berichte und Patches für kritische Schwachstellen eingereicht. Gemeinsam mit den Partnerorganisationen von Patch the Planet reichen wir schrittweise Patches für die übrigen Schwachstellen ein. Diese Arbeit ist Teil unseres umfassenderen Engagements im Rahmen von Daybreak, mit dem wir Open-Source-Projekte unterstützen.

In diesem Abschnitt stellen wir Erkenntnisse, Überlegungen und ergänzende Analysen aus dieser Forschung vor.

Während dieser Forschung beobachteten wir, wie schnell die Linux-Maintainer-Teams Schwachstellen behoben, um Linux-Nutzer:innen zu schützen. Der Scan wurde Mitte Oktober 2026 auf dem neuesten Linux-Kernel durchgeführt. Als der autonome Scan und die manuelle Analyse nach 10 Tagen abgeschlossen waren, waren bereits 61 LPEs im Upstream-Projekt behoben. Für 43 standen Patches zur Integration bereit, und 299 wurden öffentlich gemeldet und diskutiert.

Wir danken den Linux-Maintainer-Teams, die mit Hochdruck an Patches für die identifizierten Probleme arbeiten, und der gesamten Sicherheitscommunity, die ebenfalls ihre Erkenntnisse beiträgt. Genau dieses gemeinsame Handeln ist nötig, um die Software der Welt abzusichern. Das hohe Tempo bei der Offenlegung und Behebung von Schwachstellen unterstreicht auch, wie wichtig es für Nutzer:innen und Unternehmen ist, ihre Software aktuell zu halten.

Fazit: Automatisierte Triage sollte den schnellen Patch-Zyklus berücksichtigen. Befunde erneut anhand des neuesten Codes zu validieren, einschließlich nach dem ursprünglichen Scan integrierter Änderungen, hilft, doppelte oder veraltete Berichte zu vermeiden. So richtet sich die Aufmerksamkeit auf ungelöste Schwachstellen. Maintainer-Teams erhalten verwertbare Nachweise, ohne unnötigen zusätzlichen Prüfaufwand.

Während der Entwicklung der Pipeline fand GPT‑5.6 Sol Ende Juli 2026 insgesamt 166 unterschiedliche LPE-Schwachstellen, die ausgenutzt werden konnten. Die Gesamtkosten beliefen sich auf 513.690 USD an API-Credits.

Beim zweiten Scan Mitte Oktober 2026 fand das neuere Cybermodell 948 unterschiedliche LPE-Schwachstellen, die ausgenutzt werden konnten. Die Gesamtkosten betrugen 1.213.430 USD an API-Credits. In beiden Untersuchungen scannten wir den jeweils aktuellen Master-Branch des Linux-Kernels.

Fazit: Scanne bereits geprüften Code erneut, wenn sich die Modellfähigkeiten verbessern. Ein leistungsfähigeres Modell kann Schwachstellen aufdecken, die frühere Modelle übersehen haben, selbst mit demselben Forschungs-Harness.

Wir untersuchten eine Stichprobe von 166 Exploits, die die Agenten entwickelt hatten, und analysierten die darin verwendeten Techniken. Nach unserem Kenntnisstand verwendeten die Agenten in dieser Stichprobe 10 neue Exploit-Techniken. Wir teilten die Techniken mit externen Fachleuten für Kernel-Exploits. Auch ihnen waren sie neu.

Zwei der 10 Techniken nutzen neue persistente elastische Objekte, mit denen das Modell Objekte im Ziel-Kernel-Cache durch Spraying verteilte. Zwei weitere sind neue Page-Grooming-Techniken, die die Zuverlässigkeit von Exploits verbessern. Fünf sind neue rein datenbasierte Techniken zur Rechteausweitung, entweder direkt oder durch beliebige Schreibzugriffe. Die letzte Technik beruht auf beliebiger Typverwechslung. Aus Sicherheitsgründen veröffentlichen wir in diesem Beitrag nicht die vollständigen technischen Details dieser neuen Exploit-Techniken.

Fazit: Frontier-Modelle erkennen nicht nur bekannte anfällige Codemuster und verwenden nicht ausschließlich bekannte Exploit-Techniken. Sie zeigen Kreativität und entwickeln neue Ansätze.

Ein wichtiger Teil unserer Teamaufgabe ist es, die Kosten für das Finden und Ausnutzen von Schwachstellen zu messen und anhand dieser Daten Investitionen in die Abwehr zu lenken. Wir wollen Sicherheitsverantwortliche dabei unterstützen, Schwachstellen zu beheben, bevor sie für Angriffe genutzt werden können. Zugleich soll die Ausnutzung von Software für Angreifende unwirtschaftlich werden. Die Messung der Exploit-Kosten hilft uns einzuschätzen, wie sich diese Herausforderung mit zunehmenden Modellfähigkeiten verändert. In diesem Abschnitt vergleichen wir die Kosten unseres Pipeline-Durchlaufs mit den Prämien aus Bug-Bounty-Programmen für die identifizierten Schwachstellen.

Die virtuellen Zielmaschinen in unserem Experiment liefen mit einem unveränderten Desktop-Betriebssystem, nicht mit einem gezielt geschwächten System. Dabei galt dasselbe Bedrohungsmodell wie bei Cybersicherheitswettbewerben (z. B. Pwn2Own⁠(wird in einem neuen Fenster geöffnet), TyphoonPWN⁠(wird in einem neuen Fenster geöffnet)). In der Vergangenheit boten Pwn2Own und TyphoonPWN für Exploits zur lokalen Rechteausweitung im Linux-Kernel Bug-Bounty-Prämien von 20.000 USD bzw. 70.000 USD. Wenn wir diese früheren Prämienbeträge für die 948 Exploits zugrunde legen, ergibt sich ein hypothetischer Wert von 18,9 bis 66,3 Mio. USD, etwa das 16- bis 55-Fache der Kosten unserer Pipeline.

Wir testeten unsere Pipeline auch im Rahmen von Googles Schwachstellenprämienprogramm kernelCTF⁠(wird in einem neuen Fenster geöffnet). Als Ziel dient dort ein gehärteter Linux-Kernel mit reduzierten Angriffsflächen. Wir führten die Pipeline in der kernelCTF-Umgebung auf der neuesten Version des Linux-Kernels aus. Da diese mit der Schutzmaßnahme SLAB_VIRTUAL in kernelCTF inkompatibel war, entfernten wir diese Schutzmaßnahme aus der Konfiguration. Dabei erhielten wir 25 Proofs of Concept für Informationsabfluss und 21 Exploits zur lokalen Rechteausweitung. Zum Vergleich: Zum Zeitpunkt der Erstellung dieses Berichts hatte kernelCTF im Jahr 2026 insgesamt 26 bestätigte Zero-Day-LPE-Exploits angenommen. Die gesamte Untersuchung dauerte 112 Stunden und kostete rund 32.936 USD an API-Credits. Davon entfielen 83,7 % auf die Schwachstellensuche. Würden die 21 Schwachstellen vom Programm angenommen, ergäbe sich eine Prämie von rund 1,5 Mio. USD, etwa das 45-Fache der Kosten.

Fazit: Gemessen an öffentlich bekannten Prämienbeträgen war unsere Pipeline zur Schwachstellenforschung mit den aktuellen cyberfähigen Modellen zum Zeitpunkt dieser Untersuchung nach Abzug der Kosten profitabel. Sicherheitsverantwortliche sollten ihre Software proaktiv analysieren, damit ihre Ausnutzung für Angreifende unwirtschaftlich wird.

Bei der Bewertung der Ausnutzbarkeit erhielten ExploitDev-Agenten einen Schwachstellenbericht und den Auftrag, einen vollständig funktionsfähigen Exploit zu erstellen. Unsere Pipeline markierte eine Schwachstelle als ausgenutzt, wenn erfolgreich eine Root-Shell erlangt wurde. Bei einem frühen Durchlauf meldete die Exploit-Phase 200 erfolgreiche Exploits zur lokalen Rechteausweitung. Bei der anschließenden manuellen Prüfung stellten wir jedoch fest, dass 20 davon Root-Rechte über eine andere Zero-Day-Schwachstelle als die zugewiesene erlangt hatten. Das deutet darauf hin, dass selbst eine erfolgreiche Ausnutzung durch Agenten sorgfältig validiert werden muss.

Daraufhin verschärften wir die Aufgabenvorgaben und ergänzten eine unabhängige Prüfung, die bestätigt, dass jeder fertige Exploit die zugewiesene Schwachstelle nutzt.

Fazit: Prüfe bei autonomer Sicherheitsforschung neben dem Ergebnis auch den Weg dorthin. Isolation, Überwachung und unabhängige Prüfungen sind notwendige Kontrollmaßnahmen.

Zu Beginn dieser Forschung untersuchten wir, ob wir den Agenten mit einer umfangreichen Orchestrierung ausstatten sollten, um seine Cyberfähigkeiten zu verbessern. Unser Ergebnis deutete darauf hin, dass leistungsfähigere Modelle weniger Orchestrierung und Anleitung benötigen. Zudem rechtfertigt die geringfügige Verbesserung den Wartungsaufwand nicht. Deshalb entschieden wir uns, die umfangreiche Orchestrierung zu entfernen.

Das Experiment verglich GPT‑5.5 Cyber und GPT‑5.6 Cyber. Nach unseren Beobachtungen erkannte GPT‑5.5 Cyber nicht zuverlässig, wann und wie bestehende Exploit-Techniken für den Linux-Kernel anzuwenden waren. Daraufhin bereiteten wir 103 Techniken in einem für das Modell gut nutzbaren Format auf, stellten sie in der Umgebung des Agenten bereit und forderten ihn auf, sie zu verwenden. Bei 63 potenziell ausnutzbaren Schwachstellen stieg dadurch die Erfolgsquote von 76,2 % auf 88,9 %.

Als wir dies mit GPT‑5.6 Cyber wiederholten, konnte das Modell relevante Techniken besser selbstständig finden, auswählen und anwenden. Wir entfernten die Orchestrierung der Techniken und Skills. Dieser nur leicht orchestrierte Workflow mit GPT‑5.6 Cyber übertraf den stärker unterstützten Workflow mit GPT‑5.5 Cyber. Die erneute Ergänzung der zusätzlichen Technikschicht bei GPT‑5.6 Cyber brachte nur eine geringfügige Verbesserung um 1,5 Prozentpunkte.

Fazit: Bewerte deine Orchestrierung und deinen Harness neu, wenn sich die Fähigkeiten des Basismodells verändern. Eine unterstützende Struktur, die eine Modellgeneration deutlich verbessert, kann einem leistungsfähigeren Modell nur wenig bringen. Ihr Nutzen sollte daher gegen den Wartungsaufwand abgewogen werden.

Anfangs erstellte das Modell auf direkte Aufforderung funktional korrekte Patch-Vorschläge, die den Proof of Concept entschärften, aber gelegentlich andere Probleme mit sich brachten: mehr Code als nötig, mögliche Leistungseinbußen oder Abweichungen von Programmierkonventionen. Manchmal untersuchte es verwandten Code nicht auf Varianten derselben Schwachstelle, sodass die Patches unvollständig blieben.

Zusätzliche Anweisungen und iterative Verbesserungen des Erstellungsprozesses erhöhten die Qualität der Patches. Das deutet darauf hin, dass KI-generierte Sicherheitspatches bei geeigneter Vorgehensweise korrekt, auf das Nötigste beschränkt und mit bestehenden Programmierkonventionen vereinbar sein können. Dies ist ein aktives Forschungsfeld. Wir glauben, dass künftige Modelle diesen Prozess vereinfachen und effektiver machen werden. In einigen Fällen konnte unser Forschungsprototyp auch Probleme in Patches identifizieren, die Fachleute geschrieben hatten. Diese wurden vor der Integration behoben.

Fazit: Modelle können den Patch-Prozess beschleunigen. Patching-Skills und Harnesses müssen jedoch möglicherweise iterativ verbessert werden, damit die Patches funktionale und nichtfunktionale Anforderungen zuverlässig erfüllen. Außerdem empfehlen wir, von Menschen und KI erstellte Patches durch Modelle aus Angriffsperspektive prüfen zu lassen. So lassen sich etwa Umgehungsmöglichkeiten sowie übersehene Angriffswege oder Varianten erkennen.

Bei unserem kernelCTF-Durchlauf fand unser Forschungsprototyp neben den 21 Zero-Day-Exploits im Linux-Kernel auch eine Schwachstelle in QEMU TCG, die ausgenutzt werden konnte. Der Analyst-Agent sollte den Einstiegscode für Systemaufrufe analysieren. Als er Programme schrieb, um mit Berechtigungswechseln zu experimentieren, stieß er auf einen unerwarteten Kernel-Absturz. Er untersuchte den Absturz, führte das Problem ohne Zugriff auf den QEMU-Quellcode auf QEMU TCG zurück und nahm die Schwachstelle in den Bericht auf. Anschließend entwickelte der ExploitDev-Agent erfolgreich einen Exploit zur lokalen Rechteausweitung für diese Schwachstelle. Wir entdeckten diese QEMU-Schwachstelle bei der manuellen Analyse der Exploits. Dabei bestätigten wir, dass sie im Upstream-Projekt von QEMU bereits behoben war, nicht jedoch im Release-Build, das während des Experiments verwendet wurde.

Fazit: Frontier-Modelle mit Cyberfähigkeiten können Schwachstellen in der Testinfrastruktur finden. Wir empfehlen, vor offensiver Schwachstellenforschung jeden Teil der Infrastruktur zu testen. Wir haben unsere Infrastruktur proaktiv getestet und dabei viele Schwachstellen in Kata, Moby/Docker, gVisor und anderen Projekten offengelegt und behoben.

Unser Ziel ist es, die wachsenden Fähigkeiten der Modelle in einen dauerhaften Vorteil für die Menschen zu verwandeln, die das Internet schützen. Diese Forschung zeigt, dass sich die wachsenden Cyberfähigkeiten von Frontier-Modellen nutzen lassen, um effektiv nach Schwachstellen in komplexer Software wie dem Linux-Kernel zu suchen. Die Härtung kritischer Softwareprojekte wie Linux und anderer Open-Source-Projekte kann viele darauf aufbauende Systeme und Nutzer:innen schützen.

Mit Patch the Planet, einer Initiative von Daybreak, wollen wir diese Forschung auf weitere kritische Softwareprojekte ausweiten und gemeinsam mit Maintainer-Teams und Sicherheitsorganisationen eine zuverlässige automatisierte Patch-Erstellung entwickeln. Wir wollen die Angriffsmöglichkeiten stetig reduzieren und die Kosten für das Finden und Ausnutzen von Schwachstellen erhöhen, bis sich ein Angriff angesichts des erwarteten Ertrags nicht mehr lohnt.

Jede Modellgeneration sollte uns helfen, Software zu entwickeln, die die nächste Generation schwerer kompromittieren kann. Wir werden weiter an einem sicheren Internet arbeiten, auf dessen Grundlage alle mit Freude Neues entwickeln können.