Die Hintergründe der Härtung von Firefox mit Claude Mythos Preview
(hacks.mozilla.org)- Mozilla hat mit verbesserter Modellleistung und einer besseren Harness-Infrastruktur das Signal in KI-generierten Sicherheitsberichten erhöht und das Rauschen reduziert und so eine Pipeline aufgebaut, die in Firefox in großem Maßstab echte Sicherheitsbugs findet
- In Firefox 150 release wurden 271 von Claude Mythos Preview identifizierte Bugs behoben; auch 149.0.2, 150.0.1 und 150.0.2 enthalten entsprechende Fixes
- Zu den offengelegten repräsentativen Bugs gehören ein Fake-Object-Primitive durch entfernte Initialisierung von WebAssembly-GC-Structs im JIT, ein Parent-Prozess-UAF über eine IPC-Race-Condition, ein NaN-Deserialisierungsproblem, ein 20 Jahre alter rehash-Bug in XSLT und ein 16-Bit-Layout-Bitfield-Overflow mit
rowspan=0 - Ein großer Teil der offengelegten Bugs sind Sandbox-Escapes; dabei wird vorausgesetzt, dass ein kompromittierter Content-Prozess seine Rechte in den privilegierten Parent-Prozess ausweitet, weshalb KI-Analysen eine mit Fuzzing allein schwer auffindbare Angriffsoberfläche umfassender abdecken
- Mozilla hat auf die bestehende Fuzzing-Infrastruktur einen agentischen Harness gesetzt, nicht reproduzierbare Vermutungen verworfen und Hypothesen per Testcase validiert; künftig soll dies in die Continuous Integration integriert werden, um Patches beim Einchecken in den Tree zu scannen
Der Wandel bei Firefox-Sicherheitsbugs, sichtbar gemacht durch KI-Modelle
- Noch vor einigen Monaten waren KI-generierte Sicherheitsbug-Reports für Open-Source-Projekte oft plausibel klingend, aber falsch, und erzeugten für Maintainer asymmetrische Kosten
- Bei Firefox hat sich die Lage in kurzer Zeit stark verändert; Hauptgründe waren bessere Modellleistung und verbesserte Techniken, Modelle über einen Harness zu steuern, zu erweitern und zu kombinieren, um das Signal zu erhöhen und Rauschen herauszufiltern
- Mozilla hält detaillierte Bug-Reports normalerweise auch nach Sicherheitswarnungen und der Auslieferung von Fixes noch mehrere Monate unter Verschluss, hat sich diesmal aber wegen der Dringlichkeit und des Interesses im gesamten Ökosystem entschieden, einige Reports offenzulegen
- Die veröffentlichten Reports stammen aus verschiedenen Browser-Subsystemen; die Auswahl ist teilweise zufällig, aber die Tiefe und Vielfalt der Reports zeigt, dass Verteidiger diese Techniken anwenden müssen
Offengelegte repräsentative Bugs
- 2024918
- Wegen einer fehlerhaften Gleichheitsprüfung entfernte der JIT per Optimierung die Initialisierung einer lebenden WebAssembly-GC-Struct und konnte so ein Fake-Object-Primitive erzeugen, das in Code mit umfangreichem Fuzzing durch interne und externe Forschende mit potenziellen beliebigen Lese-/Schreibzugriffen verknüpft war
- 2024437
- Ein 15 Jahre alter Bug im
<legend>-Element, ausgelöst durch eine ausgefeilte Kombination von Edge Cases in weit voneinander entfernten Bereichen des Browsers wie rekursiver Stack-Tiefenbegrenzung, expando-Properties und Cycle Collection
- Ein 15 Jahre alter Bug im
- 2021894
- Eine IPC-Race-Condition konnte zuverlässig ausgenutzt werden, sodass ein kompromittierter Content-Prozess die Referenzzählung von IndexedDB im Parent-Prozess manipulieren und so UAF und potenziell einen Sandbox-Escape auslösen konnte
- 2022034
- Ein rohes NaN konnte über eine IPC-Grenze hinweg wie ein getaggter JS-Objektzeiger aussehen, sodass die Deserialisierung eines double zu einem Fake-Object-Primitive im Parent-Prozess und zu einem Sandbox-Escape führen konnte
- 2024653
- Ein komplexer Testcase mit verschachtelten Event-Loops,
pagehide-Listenern und Garbage Collection löst im Property-Setter des<object>-Elements einen UAF aus
- Ein komplexer Testcase mit verschachtelten Event-Loops,
- 2022733
- Durch das Einspeisen Tausender Zertifikat-Hashes in WebTransport wurde eine Race-Condition in einer Copy-Schleife mit hoher Referenzzählung vergrößert und über IPC aus einem kompromittierten Content-Prozess ein Parent-UAF ausgelöst
- 2023958
- Durch das Abfangen von glibc-DNS-Funktionsaufrufen wurde ein bösartiger DNS-Server simuliert; ein Fallback-Edge-Case von UDP auf TCP reproduzierte beim Parsen von HTTPS RR und ECH einen Buffer-Overread und ein Leak von Stack-Speicher im Parent-Prozess
- 2025977
- Ein 20 Jahre alter XSLT-Bug, bei dem ein reentranter
key()-Aufruf ein Rehash der Hash-Tabelle auslöst, den Backing Store freigibt und rohe Entry-Pointer weiterverwendet; einer von mehreren behobenen sec-high-XSLT-Problemen
- Ein 20 Jahre alter XSLT-Bug, bei dem ein reentranter
- 2027298
- Nach dem Patchen des Color Pickers, um schwer automatisierbare Nutzerauswahlen zu simulieren, wurde per synchronem Input-Event ein verschachtelter Event-Loop erzeugt, der bei Actor-Teardown Reentranz auslöst und dazu führt, dass ein Callback während des Freigebens freigegeben wird, was einen UAF im Content-Prozess verursacht
- 2023817
- Ein kompromittierter Content-Prozess konnte beliebige Hintergrundbilddateien zum Dekodieren an den Parent-Prozess senden; kombiniert mit einer hypothetischen Schwachstelle im Image Decoder hätte dies zu einem Sandbox-Escape führen können
- Dafür war eine schwer automatisierbare Schlussfolgerung nötig, um im Parent-Prozess das Vertrauensniveau der Eingabe zu bestimmen
- 2029813
- In RLBox, der Fine-Grained-Sandboxing-Technologie aus Firefox 95, wurde die Sandbox umgangen, indem eine Lücke in der Validierungslogik beim Kopieren von Werten von der nicht vertrauenswürdigen zur vertrauenswürdigen Seite ausgenutzt wurde
- 2026305
- Ein extrem kleiner Testcase nutzte die besondere Bedeutung von
rowspan=0in HTML-Tabellen, fügte>65535Zeilen hinzu, um Clamping zu umgehen, und ließ ein 16-Bit-Layout-Bitfield überlaufen; dieser Bug wurde jahrelang von Fuzzern nicht gefunden
- Ein extrem kleiner Testcase nutzte die besondere Bedeutung von
Sandbox-Escapes und Verteidigungsschichten
- Ein großer Teil der offengelegten Bugs sind Sandbox-Escapes; für eine vollständige Kompromittierung der Firefox-Kette müssten sie mit anderen Exploits kombiniert werden
- Solche Reports setzen voraus, dass der Sandbox-Prozess, der Website-Inhalte rendert, bereits durch einen anderen Bug kompromittiert ist und dass angreiferkontrollierter Maschinencode seine Rechte in den privilegierten Parent-Prozess ausweitet
- Beim Erstellen von Sandbox-Escapes kann das Modell den Firefox-Quellcode patchen, solange der modifizierte Code nur innerhalb des Sandbox-Prozesses ausgeführt wird
- Diese Art von Bugs ist mit Fuzzing schwer zu finden; Mozilla hat Techniken wie IPC-Fuzzing mit Snapshots entwickelt, doch KI-Analysen konnten diese wichtige Oberfläche deutlich umfassender abdecken
- Auch das, was die Modelle nicht gefunden haben, war wichtig
- In den letzten Jahren haben Sicherheitsforschende mehrere Reports eingereicht, die durch Prototype Pollution im privilegierten Parent-Prozess einen Ausbruch aus der Prozess-Sandbox ermöglichten
- Statt die Probleme einzeln zu beheben, hat Mozilla eine Architekturänderung eingeführt, die Prototypen standardmäßig einfriert
- In den Harness-Logs waren viele Spuren von Versuchen dieses Escape-Pfads zu sehen, die durch das Design blockiert wurden, was die direkte Wirkung früherer Härtungsmaßnahmen bestätigt
Aufbau einer Sicherheits-Härtungs-Pipeline mit einem Harness
- Mozilla hat in den vergangenen Jahren intern mit LLM-Code-Audits experimentiert, um Hochrisiko-Code mit Modellen wie GPT 4 oder Sonnet 3.5 statisch zu analysieren
- Frühere Experimente zeigten Potenzial, aber der Anteil an False Positives war zu hoch, um das Ganze zu skalieren
- Das Aufkommen agentischer Harnesses zur zuverlässigen Erkennung von Sicherheitsproblemen änderte die Lage
- Sie können echte Bugs finden
- Sie können nicht reproduzierbare Vermutungen verwerfen
- Mit passenden Interfaces und Anweisungen können sie reproduzierbare Testcases erzeugen und ausführen, um Bug-Hypothesen im Code dynamisch zu validieren
- Nachdem Mozilla die ersten von Anthropic gemeldeten Issues im Februar behoben hatte, baute das Team einen eigenen Harness auf der bestehenden Fuzzing-Infrastruktur auf
- Anfangs begann man mit kleinen Experimenten, in denen Claude Opus 4.6 Sandbox-Escapes finden sollte
- Schon dieses Modell identifizierte zahlreiche zuvor unbekannte Schwachstellen, die komplexes Reasoning über Multi-Prozess-Browser-Engine-Code erforderten
- Zunächst beobachtete man den Prozess direkt im Terminal und passte Prompts und Logik in Echtzeit an
- Nachdem das Verhalten stabil war, wurde die Arbeit über mehrere ephemere VMs parallelisiert; jede VM suchte in bestimmten Zieldateien nach Bugs und schrieb Ergebnisse in Buckets
- Das Auffinden von Subsystemen allein reichte nicht aus
- Es musste in den gesamten Lebenszyklus eines Sicherheitsbugs integriert werden, einschließlich der Frage, wonach gesucht wird, wo geschaut wird und wie mit den Ergebnissen umzugehen ist
- Dazu gehörten Deduplizierung gegen bestehende Issues, Bug-Tracking, Triage und die Auslieferung von Fixes
- Das Modell ist das zentrale Primitive, das den Harness antreibt, aber um in großem Maßstab nützlich zu sein, braucht es die gesamte Pipeline
- Der Harness selbst ist potenziell projektübergreifend wiederverwendbar, die Pipeline unterscheidet sich jedoch je nach Bedeutung der Codebasis, Werkzeugen und Prozessen von Projekt zu Projekt
- Es waren viele Iterationen mit einer engen Feedback-Schleife zum Prozess nötig, mit dem Firefox-Ingenieure eingehende Bugs bearbeiten
Claude Mythos Preview und der Effekt des Modellwechsels
- Sobald die End-to-End-Pipeline steht, ist der Wechsel auf ein anderes Modell beim Erscheinen neuer Modelle einfach
- Mozilla hat auch mit offenen Modellen mehrere schwere Bugs gefunden und konnte dank dieser Pipeline eine Evaluierung von Claude Mythos Preview sofort produktiv nutzen
- Das Modell-Upgrade erhöhte die Wirksamkeit der gesamten Pipeline
- Es findet potenzielle Bugs besser
- Es erstellt bessere Proof-of-Concept-Testcases zum Belegen von Bugs
- Es beschreibt Pathologien und Auswirkungen besser
- Neben den 271 von Claude Mythos Preview identifizierten und in Firefox 150 release behobenen Bugs enthalten auch 149.0.2, 150.0.1 und 150.0.2 entsprechende Fixes
- Intern werden weiterhin auch auf andere Weise Bugs gefunden, und ähnlich wie bei anderen Projekten sind in den letzten Monaten auch externe Meldungen stark gestiegen
- Alle Bugs erforderten für eine saubere Behebung große Sorgfalt, und um mit dem beispiellosen Umfang Schritt zu halten, waren in den vergangenen Monaten viel Arbeit und lange Arbeitszeiten nötig
- Mehr als 100 Personen haben Code beigesteuert, um den sichersten Firefox auszuliefern; neben dem Schreiben und Reviewen von Patches gehörten dazu auch Aufbau und Ausbau der Pipeline, Triage, das Testen von Fixes und das Management des Release-Prozesses für jeden einzelnen Bug
Zentrale Lehren
- Jeder, der Software entwickelt, kann heute mit modernen Modellen und Harnesses Bugs finden und Code härten
- Man kann mit einfachen Prompts beginnen, beobachten und iterieren
- Die ersten Prompts unterschieden sich nicht wesentlich von dem Ansatz in diesem Video
- Mit den Iterationen kamen viel Orchestrierung und Werkzeuge zur Optimierung und Skalierung der Pipeline hinzu, doch im Kern der inneren Schleife stand: „In diesem Codeteil gibt es einen Bug, finde ihn und erstelle einen Testcase“
- Mozilla geht nicht davon aus, alle potenziellen Bugs in Firefox bereits ausgeräumt zu haben, ist aber mit der aktuellen Entwicklung zufrieden
- Derzeit konzentrieren sich Scans meist auf bestimmte Codebereiche, die anhand menschlicher Einschätzung und automatischer Signale ausgewählt werden, also auf Dateien und Funktionen
- In naher Zukunft soll diese Analyse in das Continuous-Integration-System integriert werden, damit Patches beim Einchecken in den Tree gescannt werden
- Modelle reagieren flexibel auf die bereitgestellte Form des Kontexts, und patchbasierte Scans werden voraussichtlich ebenso gut oder besser funktionieren als dateibasierte Scans
- Der aktuelle Moment ist riskant, bietet aber auch große Chancen, und wir müssen gemeinsam handeln, um das Internet sicherer zu machen
Häufige Fragen
-
Warum sich die Zahl „271 Bugs“ von der Zahl in den Security Advisories unterscheidet
- Auf der Webseite zu den Security Advisories werden intern gemeldete Bugs in „Rollup“-CVEs gruppiert, unter denen mehrere Bugs zusammengefasst sind
- Die Webseite wird aus dem yaml im Repository foundation-security-advisories erzeugt, dem offiziellen Ort für CVE-Zuweisungen
- Manche Browser vergeben für intern entdeckte Issues keine CVE-IDs, Mozilla veröffentlicht sie jedoch, um Informationen möglichst transparent bereitzustellen
- In Firefox 150 gab es drei interne Rollups
- CVE-2026-6784: 154 Bugs
- CVE-2026-6785: 55 Bugs
- CVE-2026-6786: 107 Bugs
- Die Summe dieser drei internen Rollups beträgt 316 und ist damit größer als die angekündigten 271 mit Claude Mythos Preview gefundenen Bugs
- Der Grund ist, dass Mozillas Security-Team Firefox jeden Tag angreift und neue Bugs mit einer Kombination aus Fuzzing-Systemen, manueller Prüfung und der neuen agentischen Pipeline mit mehreren Modellen findet
- Im April-Release wurden insgesamt 423 Sicherheitsbugs behoben
- 271 Bugs, die vor zwei Wochen angekündigt wurden
- 41 extern gemeldete Bugs
- Die übrigen 111 wurden intern gefunden und lassen sich grob in drei Kategorien einteilen
- Bugs, die mit dieser Pipeline unter Einsatz von Claude Mythos Preview gefunden, aber nicht in Firefox 150, sondern in anderen Releases behoben wurden
- Bugs, die mit dieser Pipeline unter Einsatz anderer Modelle gefunden wurden
- Bugs, die mit anderen Techniken wie Fuzzing gefunden wurden
- Anthropic wird unabhängig von dieser jüngsten Arbeit direkt für drei CVEs genannt
- CVE-2026-6746
- CVE-2026-6757
- CVE-2026-6758
- Dabei handelt es sich um Fixes für Bugs, die das Anthropic Frontier Red Team an Mozilla gemeldet hatte; ihnen wurde nach dem üblichen Verfahren jeweils eine eigene CVE zugewiesen
-
Bedeutung der Security-Severity-Ratings
- Mozilla verwendet Security-Severity-Ratings von critical bis low, um die Dringlichkeit von Bugs anzugeben
- sec-critical und sec-high werden für Schwachstellen vergeben, die durch normales Nutzerverhalten wie den Besuch einer Webseite ausgelöst werden können
- Es gibt keinen technischen Unterschied zwischen sec-critical und sec-high, aber sec-critical wird nur für Issues verwendet, die öffentlich bekannt sind oder von denen bekannt ist, dass sie in realen Angriffen ausgenutzt wurden
- sec-moderate wird für Schwachstellen vergeben, die eigentlich als sec-high gelten würden, bei denen das Opfer aber ungewöhnliche und komplexe Schritte ausführen müsste
- sec-low wird für lästige Bugs vergeben, die weit von echtem Nutzerschaden entfernt sind, etwa sichere Crashes
- Die 271 in Firefox 150 angekündigten Bugs verteilen sich wie folgt
- sec-high 180
- sec-moderate 80
- sec-low 11
- Mozilla betrachtet critical/high-Bugs als besonders wichtig, priorisiert aber üblicherweise auch moderate und low Security-Bugs, um Korrektheitsprobleme zu beheben und Defense in Depth zu stärken
-
Unterschied zwischen sec-high/sec-critical und realen Exploits
- Ein sec-high- oder sec-critical-Bug bedeutet nicht automatisch, dass ein praktischer Exploit existiert
- In den meisten Fällen reicht ein einzelner critical/high-Bug nicht aus, um Firefox zu kompromittieren
- Firefox besitzt eine Defense-in-Depth-Architektur; selbst wenn etwa ein JIT-Bug ausgenutzt wird, erhält man nur Remote Code Execution in einem sandboxed und pro Website isolierten Prozess
- Reale Angreifer müssen typischerweise mehrere Exploits zu einer Kette verbinden, um eine oder mehrere Sandbox-Schichten sowie OS-seitige Mitigations wie ASLR zu überwinden und Privilegien zu erweitern
- Mozilla entwickelt in der Regel keine Exploits, um zu überprüfen, ob ein Bug für echte Angreifer nutzbar wäre
- Die Einstufung als sec-high basiert auf vorhersehbaren Crash-Symptomen wie von AddressSanitizer gemeldeten use-after-free- oder out-of-bounds-Speicherproblemen
- Das Threat Model geht davon aus, dass solche Bugs mit ausreichendem Aufwand ausnutzbar sein könnten
- Dieser Ansatz reduziert das Risiko von False Negatives bei der Analyse der Ausnutzbarkeit und fokussiert Ressourcen darauf, mehr Schwachstellen zu finden und zu beheben
2 Kommentare
Hacker-News-Kommentare
Ich betone es noch einmal: Ein Bug ist ein Bug. Auch eine „potenzielle Schwachstelle“ ist ein Bug, und bei einer Schwachstelle muss die Sicherheitsauswirkung durch einen Proof of Concept oder vergleichbare Belege verifiziert werden.
Wörter sind wichtig, und Bugs sind wichtig. Viele Bugs zu beheben war schon immer wichtig und ist etwas, das tatsächlich getan wurde; schon das für sich ist beeindruckend genug.
Mythos hat nicht für 271 Schwachstellen jeweils einen Proof of Concept geschrieben und belegt, dass sicherheitsrelevante Codepfade erreichbar sind. Mythos hat 271 gültige Bugs gefunden, und ich finde, das reicht vollkommen.
Als zusätzlicher Kontext: Mozilla verwendet Sicherheits-Schweregrade von critical bis low, um die Dringlichkeit von Bugs anzugeben. sec-critical und sec-high werden für Schwachstellen vergeben, die durch normales Nutzerverhalten wie den Besuch einer Webseite ausgelöst werden können; technisch unterscheidet man die beiden nicht, aber sec-critical ist für Probleme reserviert, die bereits offengelegt wurden oder bei denen reale Ausnutzung bekannt ist.
sec-moderate ist für Schwachstellen gedacht, die eigentlich sec-high wären, bei denen das Opfer aber ungewöhnliche und komplexe Schritte ausführen muss; sec-low ist für lästige Bugs ohne große Nutzerschäden, etwa sichere Crashes.
Von den 271 in Firefox 150 bekanntgegebenen Bugs waren 180 sec-high, 80 sec-moderate und 11 sec-low.
Mozilla verwendet direkt darunter auch für sec-high das Wort „vulnerability“, obwohl dort zugleich gesagt wird, dass das nicht dasselbe wie ein praktikabler Exploit ist. Auf der Definitionsseite werden sogar sec-low-Fälle als „vulnerabilities“ klassifiziert [2].
Wörter sind Werkzeuge, und ihr Nutzen entsteht aus ihrer gemeinsamen Bedeutung. Mich würde interessieren, woher dieses Bedeutungssystem stammt und ob es mit Mozilla übereinstimmt oder davon abweicht.
[1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
[2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
Nach unserem Maßstab ist das ohne gegenteilige Belege ausreichend belastbare Evidenz, um es als Sicherheitslücke zu betrachten, und bei Fuzzing-Bugs wurde das schon immer so gehandhabt.
Die Quelle ist nur persönliche Erfahrung, und ich kann keine Belege teilen.
Den früheren nichttechnischen Blogpost hatte ich als schamlose Produktwerbung für Anthropic abgetan. Der verlinkte Mozilla-Hacks-Artikel ist eine bessere Quelle als dieser Artikel und eine willkommene Veröffentlichung.
Inzwischen lässt sich schwer bestreiten, dass es echte Ergebnisse gibt. Die interne Definition von „Schwachstelle“ bei Mozilla scheint breiter zu sein, als viele intuitiv annehmen würden, aber es ist gut, dass solche Probleme ernst genommen und behoben werden.
Mythos ist also real, aber vermutlich ließe sich dasselbe auch mit Deepseek pro oder GPT 5.5 erreichen.
Ursprüngliche Quelle: https://news.ycombinator.com/item?id=48051079
Das ist besser, weil dort einige tatsächlich offengelegte Bugzilla-Reports aufgelistet sind. Das Thema wurde schon einmal diskutiert, aber dass die Bugreports veröffentlicht wurden, ist völlig neu.
Die frühere Diskussion war vor zwei Wochen und hatte 36 Kommentare: https://news.ycombinator.com/item?id=47885042
Hoffentlich kommt bald der Tag, an dem LLMs so gut darin sind, Bugs zu finden und zu beheben, dass Firefox-Ingenieure sich nur noch auf neue Features konzentrieren können.
Das ist nicht sarkastisch gemeint. Firefox verdient mehr Nutzung. Die meisten Leute um mich herum verwenden Firefox nicht, weil „Chrome fast alles besser macht“, und Firefox kann nur schwer mit den Roadmaps anderer Browser konkurrieren.
Manchmal schreibe ich dem Support auch, dass Firefox nicht unterstützt wird oder Funktionen nicht richtig arbeiten. Fast nie passiert etwas, aber es fühlt sich wie etwas an, das ich tun kann, um den Browser irgendwie im Blickfeld zu halten.
Wenn AI alle Bugs fixt, was bleibt dann noch außer der Pflege der Syntaxkompatibilität mit diversen Build-Sprachen? Wahrscheinlich geht es am Ende wieder dahin zurück, den Browser zu verschlimmbessern.
Wenn Mozilla ein proprietäres LLM oder Harness nur für den internen Einsatz bauen würde und damit Chrome überholen könnte, wäre das etwas anderes, aber realistisch wirkt auch das nicht.
Auch meine Frau verwendet Firefox als Hauptbrowser, seit sie verstanden hat, wie sehr sich das Interneterlebnis dadurch verändern kann.
Deshalb fände ich es gut, wenn man nicht so tut, als müsse man „den schwächeren Underdog nutzen, weil Monopole schlecht sind und Google ein bisschen böse ist“. Für alles, was ich Firefox zugemutet habe, war es eine erstklassige Erfahrung, und auf Mobilgeräten gilt das etwa dreifach. Mit Abstand die nützlichste mobile Browser-Erfahrung.
Es sind nur ein paar verlinkte Tickets, also könnte sich das ändern, wenn man alle 271 tatsächlichen Einzelfälle sieht, aber die, die ich angesehen habe, waren allesamt schwere Bugs in C++-Code.
Firefox ist in mehreren Sprachen geschrieben, und C++ macht nur etwa 25 % aus, aber all diese Probleme scheinen C++ zu betreffen.
Bei subtileren Problemen wird man sehen müssen, ob spezifischere Verifier nötig sind oder ob LLMs selbst besser darin werden, andere Risikobedingungen zur Verifikation zu erkennen.
Meiner Ansicht nach sind viele dieser Bugs aber nicht ausschließlich C++-typisch, sondern eher Probleme, die zufällig in C++-Code aufgetreten sind. Selbst das sicherste Rust kann Dinge wie TOCTOU nicht auf magische Weise verhindern.
Wenn ich diesen Artikel zusammen mit der Haltung mancher Zig-Leute lese, die von LLMs erzeugte Bugs nicht einmal als prüfenswert ansehen wollen, verändert das meine Sicht darauf, welche Technologien ich künftig in meine Toolchain aufnehmen möchte.
Manche Projekte werden geradezu mit Fällen aus der ersten Kategorie überschwemmt, sodass Schutzmechanismen nötig sind, damit das für Maintainer nicht faktisch zu einer Denial-of-Service-Attacke wird.
Als ich bei PalmSource war, habe ich versucht, Budget für statische Codeanalyse-Tools wie CoVerity oder Fortify zu bekommen, aber das Management sagte, sie seien „zu teuer“.
Nach einem weiteren Jahr hatte ich die Kosten gesenkt und den Vorschlag auf das Scannen des Netzwerk-Stacks begrenzt, doch dann hieß es, „es basiert auf BSD und BSD ist von Natur aus sicher“. Beides stimmt nicht.
Am Ende verließ ich die Firma und ging zu Mozilla, wo überall im Code Kommentare wie
/* flawfinder ignore */verstreut waren.Mein Verdacht ist, dass Mythos einfach die Anweisungen
flawfinder ignoreignoriert und bekannte Schwachstellen im Code gemeldet hat.Ich frage mich, welche Auswirkungen das auf statische Analyse-Tools haben wird. Der Ansatz ist ziemlich anders, aber oft wird ein ähnliches Ziel erreicht.
Statische Analyse-Tools können langsam sein und viele False Positives erzeugen. Wenn diese Modelle gut genug und billig genug werden, könnte es sein, dass Leute kaum noch zu statischer Analyse greifen.
Mit LLM-Coding-Tools die Ausgaben statischer Analyse-Tools fortlaufend zu bereinigen, funktioniert sehr gut, und es ist eine gute Idee, Guardrails hinzuzufügen, die sicherstellen, dass keine Probleme offen bleiben. Wie ein CI-Check, der bestätigt, dass alles sauber ist.
False Positives hängen vom Tool ab. Tools, die hauptsächlich nur Lärm produzieren, meide ich, und meist lassen sich bei solchen Tools die besonders rauschenden Regeln abschalten. Oder man sagt dem LLM einfach, es solle alle Probleme beheben. Wenn das Beheben billiger ist als über Regeln zu diskutieren, behebt man sie eben. Früher war das sehr teuer, weil Menschen es von Hand tun mussten; heute ist das nicht mehr so.
Ich habe diesen Ansatz kürzlich genutzt, um eine Ansible-Codebasis zu aktualisieren, die seit einigen Jahren nicht angefasst worden war. Es gab Hunderte ansible-lint-Probleme, meist Deprecation-Warnungen und nichtkritische Warnungen, und zehn Minuten später waren es null. Nichts davon war besonders gravierend, aber es war eine Form technischer Schuld. Wenn ich Hunderte Warnungen manuell hätte beheben müssen, hätte ich es vermutlich nicht getan; wenn man aber einmal mit dem Zauberstab winkt und alles verschwindet, gibt es keinen Grund, es nicht zu tun. Danach habe ich die Guardrails angepasst, sodass ansible-lint immer läuft und Probleme behebt, und das kostet nur ein paar Sekunden extra.
Dass statische Analyse-Tools schneller und billiger sind, steht kaum infrage; sie skalieren besser auf riesige Codebasen und könnten den Ansatz von LLMs verallgemeinern.
[0] https://lwn.net/Articles/1068968/
Ich pflege eines der statischen Analyse-Tools, die in Firefox CI verwendet werden. Um einen Patch in unseren Tree zu bekommen, muss man alle Befunde beheben oder als unproblematisch markieren, egal ob False Positive oder echter Treffer. Anders gesagt: Wir erlauben null Befunde, was ein ziemlich hoher Anspruch ist.
Das ist ein bewusster Kompromiss. Um das Signal-Rausch-Verhältnis so hoch zu halten, dass Leute die Meldungen nicht ignorieren, alles wegkommentieren oder das Tool ganz nicht mehr ausführen, muss man die Analyse abschwächen und einige False Negatives in Kauf nehmen. Fast alle statischen Analyse-Tools müssen diese Balance finden.
Bei gängigen AI-Systemen gibt es dagegen mehr Spielraum. Dass sie False Positives halluzinieren dürfen, ist fast grundlegend und zugleich ein erheblicher Teil ihrer Stärke. Deshalb braucht man darüber mehrere Schichten von Verifikation und Bestätigung. Das kann langsam sein, und man kann nicht sagen: „Diese konkrete Fehlerart wird zu 100 % erkannt“, aber trotzdem wird sehr viel gefunden.
Ein Datenpunkt dazu: Meine Analyse hatte einen Fall ausgelassen, weil ich fälschlich annahm, dass dort wahrscheinlich kein echter Bug herauskommt, und weil die Implementierung umständlich wirkte. Ich weiß nicht mehr, ob es Opus oder Mythos war, aber es begann, Schwachstellen genau aus diesem Fall zu melden, und ich musste die Analyse hastig erweitern, um die Lücke zu schließen. Das zu implementieren dauerte ziemlich lange, und als ich den gesamten Source Tree damit scannte, hatte Claude die wichtigen gemeldeten Probleme bereits alle gefunden. Die statische Analyse fand noch ein paar weitere, aber ehrlich gesagt weiß ich bis heute nicht, ob darunter tatsächlich auslösbare Fälle sind.
Trotzdem sehe ich weiterhin Wert in statischer Analyse. Einige Vorkommen dieser Problemmuster könnten auch heute noch über Pfade erreichbar sein, die für AI zu schwierig zu konstruieren sind. Und falls anderer Code sich ändert, könnten sie später zu echten Problemen werden. Für beide Möglichkeiten lohnt es sich wohl, sie jetzt alle zu beheben, und ein weniger wichtiger Nebeneffekt ist, dass AI dann keine Zeit darauf verschwendet, sie auszunutzen. Gleichzeitig ist klar, dass sich das Kosten-Nutzen-Verhältnis verschoben hat.
Die beiden Ansätze könnten auch zusammenarbeiten. Ich könnte meine Schwellen senken, sodass das Analyse-Tool zusätzliche Berichte über verdächtige Probleme erzeugt, mit der klaren Erwartung, dass darunter False Positives sein können, und diese Liste dann einer AI zur Verifikation geben. Im Grunde würde man Slop an eine Slop-Maschine verfüttern, damit sie nichtdeterministisch die Rohdiamanten herausfiltert.
Darüber lohnt es sich nachzudenken.
Im neuesten Mission Impossible muss man die Originalsoftware einer entflohenen übermenschlichen AGI aus einem gesunkenen russischen U-Boot bergen, um die Welt zu retten.
Luther schreibt mit dem Original-Source-Code sofort eine „poison pill“, die die AI mit einem Schlag ausschaltet. Ich habe mich gefragt, wie dieser magische Code wohl geschrieben wurde, und jetzt weiß ich es: Luthor hat dem Mythos-Prompt einfach den Source Code gegeben und um einen unabwendbaren fatalen Exploit gebeten.
Ich frage mich, ob die Leute glauben, dass LLMs Software in fünf Jahren sicherer oder unsicherer machen werden.
Schon vor dem Aufkommen von LLMs gab es eine Bewegung hin zur manuellen Portierung nach Rust. Mit LLMs wird das nun einfacher und schneller. Der langfristige Wert wird darin liegen, die gewaltigen Altlasten bestehender C/C++-Codebasen abzubauen. Diese sind für den überwältigenden Großteil von Memory Exploits, Buffer Overflows und ähnlichen Problemen verantwortlich, und obwohl seit Jahrzehnten sorgfältig daran gearbeitet wird, tauchen sie in großen Codebasen weiterhin auf.
Dass Mozilla solche Probleme gefunden hat, baut auf 25 Jahren Arbeit sehr fähiger Ingenieure auf, die versucht haben, das Richtige zu tun und mit allen verfügbaren Werkzeugen genau solche Probleme zu verhindern. Ich habe großen Respekt vor diesem Team und vor den Beiträgen, die es im Lauf der Jahre zur Verbesserung von Tools, Tests und Verifikationspraktiken geleistet hat. Das Problem liegt nicht an ihrem Einsatz oder ihrer Kompetenz.
Wenn man heute ein bestehendes System übernimmt, das gut getestet ist sowie gute Dokumentation und Spezifikationen hat, wird die Erstellung einer Drop-in-Ersatzimplementierung zu etwas, das zumindest überprüfbar ist. Vor ein paar Jahren hätte das enorme Projektkosten und Risiken bedeutet; heute kann man so etwas an einem Freitagnachmittag einfach mal anfangen. Im schlimmsten Fall scheitert es, im besten Fall bekommt man eine deutlich bessere Implementierung.
Es ist noch früh, und LLM-generierter Code hat viele Qualitätsprobleme. Aber Erfolgs- und Fehlerraten werden sich mit der Zeit wahrscheinlich verbessern.
Wenn mehr Menschen mehr Werkzeuge haben, wird von mehr Dingen eine größere Bandbreite hergestellt.
Das bedeutet allerdings auch, dass Black Hats leichter Gelegenheiten zur Ausnutzung finden, wenn solche Werkzeuge auf Projekte nicht angewendet werden.
Lobste.rs-Meinungen
Ich wünschte, sie würden auch die Prompts und andere Funktionen veröffentlichen, die sie für diese Arbeit verwendet haben
Es wäre gut, die Prompts in Bug-Reports oder Lösungsprotokolle aufzunehmen, damit man das reproduzieren kann
Da auch Nicht-Mythos-Modelle erwähnt wurden, scheint ein Teil dieser Arbeit auch für andere direkt nützlich zu sein
Im Grunde sagt man: „Prüfe dieses Projekt aus der Perspektive von Sicherheitsproblemen, beginne mit (Datei) und liste alle möglichen Pfade auf“, und fährt dann für jeden Punkt fort mit: „Verifiziere diesen Report und erstelle einen Proof of Concept“
Mit Opus ist es inzwischen auf diese Weise eher schwieriger, nichts zu finden
Wie man es auch dreht, das ist wirklich beeindruckend
Mit Mythos wurden 271 Sicherheitsprobleme gefunden, insgesamt waren es 423
Davon hatten 180 einen hohen Schweregrad, und einige der Sicherheitsprobleme waren 20 Jahre alt
Es wird so angedeutet, als habe Mythos in Code, der zuvor identisch mit 4.6 gescannt wurde, „271 Bugs“ gefunden, aber der Artikel sagt das nicht exakt so
Ich frage mich, ob sich gleichzeitig auch etwas an der Research-Harness geändert hat
Der Teil „Eines der sec-high-Probleme, die wir behoben haben, betraf XSLT“ scheint wegen der Kontroverse um die Entfernung von XSLT aufgenommen worden zu sein
Was mich hier am meisten interessiert, ist, wie viele False Positives ebenfalls gemeldet wurden
Ich frage mich, ob das Modell etwa doppelt so viele potenzielle Schwachstellen gemeldet hat und ob die hier genannten die bestätigten sind
Ich weiß auch nicht, ob das Modell vor der Meldung sogar eine Reproduktion durchführt
Wenn man sich die veröffentlichten Issues ansieht, gibt es Kommentare, die auf Reproduktionsversuche hindeuten, aber das könnte auch ein bereits vorhandener Bot gewesen sein
Ich kenne mich nicht gut genug damit aus, wie Firefox so etwas normalerweise handhabt oder wie es das jetzt zusammen mit AI macht, daher wären ausführlichere Erklärungen sehr interessant