Die Hintergründe der Härtung von Firefox mit Claude Mythos Preview

• 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
• 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
• 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
• 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=0 in HTML-Tabellen, fügte >65535 Zeilen hinzu, um Clamping zu umgehen, und ließ ein 16-Bit-Layout-Bitfield überlaufen; dieser Bug wurde jahrelang von Fuzzern nicht gefunden

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

[GN⁺]

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

  • Bei den meisten Projekten ist die Einstiegshürde wirklich niedrig
    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
  • Glaubst du, dass der Prompt über „Finde Sicherheitslücken in dieser Codebasis“ hinausgeht?

• 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

  • Wie fair der Vergleich zwischen Opus 4.6 und Mythos war, ist nicht ganz klar
    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