8 Punkte von GN⁺ 2026-03-07 | 2 Kommentare | Auf WhatsApp teilen
  • Claude Opus 4.6 entdeckte in Zusammenarbeit mit Mozilla 22 Schwachstellen in Firefox, von denen 14 als kritisch mit hohem Risiko eingestuft wurden
  • Dies belegt, dass ein KI-Modell Zero-Day-Schwachstellen in komplexer Software schnell erkennen kann; die Korrekturen wurden in Firefox 148.0 übernommen
  • Claude analysierte Tausende von Dateien, darunter Bereiche des JavaScript-Engines, und reichte 112 Berichte ein, auf deren Grundlage Mozilla Korrekturen umsetzte
  • Es zeigte sich, dass KI zwar hervorragend beim Erkennen von Schwachstellen ist, ihre Fähigkeit zur Erstellung tatsächlicher Exploits (Angriffscode) jedoch begrenzt ist
  • Anthropic stellt ein KI-basiertes Modell für die Zusammenarbeit in der Sicherheitsforschung vor und ruft in Kooperation mit dem Open-Source-Ökosystem zu einer verteidigerzentrierten Stärkung der Sicherheit auf

Überblick über die Zusammenarbeit mit Mozilla

  • Claude Opus 4.6 fand in zwei Wochen Analyse 22 Firefox-Schwachstellen; Mozilla stufte davon 14 als hohes Risiko ein
    • Das entspricht etwa 20 % der 2025 in Firefox behobenen Schwachstellen mit hohem Risiko
    • Die Korrekturen wurden in Firefox 148.0 aufgenommen und an Hunderte Millionen Nutzer verteilt
  • Mozilla validierte die Berichte von Anthropic und teilte Standards und Prozesse für Bug Reports, um ein kooperatives Verifikationssystem aufzubauen
  • Diese Zusammenarbeit wird als Beispiel für ein Kooperationsmodell zwischen KI-basierter Sicherheitsforschung und Maintainers vorgestellt

Prozess der Schwachstellenerkennung mit KI-Modellen

  • Anthropic erstellte einen Firefox-CVE-Datensatz, um über den CyberGym-Benchmark hinaus realitätsnahe Tests durchzuführen
    • Firefox ist ein komplexes und sicherheitskritisches Open-Source-Projekt und damit ein geeignetes Ziel, um die Erkennungsfähigkeit von KI zu validieren
  • Claude reproduzierte zunächst frühere CVEs und nahm dann die Erkennung neuer Schwachstellen in der aktuellen Version in Angriff
    • Bereits in den ersten 20 Minuten wurde eine Use-After-Free-Speicherschwachstelle gefunden, unabhängig verifiziert und anschließend an Mozilla gemeldet
  • Danach analysierte Claude mehr als 6.000 C++-Dateien und reichte 112 einzigartige Berichte ein
    • Die meisten Probleme wurden in Firefox 148 behoben, einige sollen in künftigen Versionen gelöst werden

Experimente mit Schwachstellen-Exploits

  • Um die Obergrenze von Claudes Sicherheitsfähigkeiten zu bewerten, wurde getestet, ob sich entdeckte Schwachstellen in tatsächlichen Angriffscode umwandeln lassen
    • Es wurden Hunderte von Tests und etwa 4.000 US-Dollar an API-Kosten investiert
    • Am Ende waren nur 2 tatsächliche Exploits erfolgreich; im Vergleich zur Erkennungsfähigkeit war die Fähigkeit zur Erzeugung von Angriffen gering
  • Die erfolgreichen Exploits funktionierten nur in der Testumgebung, in der die Sandbox-Sicherheitsfunktionen des realen Browsers entfernt worden waren
    • Das mehrschichtige Verteidigungssystem von Firefox kann solche Angriffe abschwächen
  • Anthropic warnt auf Basis dieses Experiments vor der Möglichkeit, dass KI Angriffswerkzeuge automatisch erzeugen könnte

Best Practices für KI-basierte Sicherheitsforschung

  • Mit der Forschung zu einem Patching Agent entwickelte Anthropic Methoden, mit denen LLMs Bugfixes und deren Verifikation durchführen können
    • Dabei wird ein Hilfswerkzeug namens Task verifier eingesetzt, um die Ergebnisse der KI in Echtzeit zu validieren
    • Es wird automatisch getestet, ob die Schwachstelle entfernt wurde und ob die Programmfunktionalität erhalten bleibt
  • Die zentralen Bestandteile der von Mozilla als vertrauenswürdig eingestuften Berichte waren drei Elemente
    • ein minimaler reproduzierbarer Testfall
    • ein detaillierter Proof-of-Concept
    • potenzieller Patch-Code
  • Forschenden wird empfohlen, bei LLM-basierten Schwachstellenmeldungen stets nachprüfbare und reproduzierbare Belege mit einzureichen

Ausblick und Bedarf an stärkerer Sicherheit

  • Claude Opus 4.6 fand nicht nur in Firefox, sondern auch in wichtigen Projekten wie dem Linux-Kernel Schwachstellen
  • Derzeit sind die Erkennungs- und Behebungsfähigkeiten von KI den Fähigkeiten zur Exploit-Erstellung überlegen, was für Verteidiger vorteilhaft ist
  • Angesichts der Geschwindigkeit der Modellentwicklung könnte sich die Lücke bei den Angriffsfähigkeiten jedoch schnell schließen
  • Anthropic stellt über Claude Code Security Funktionen zur Schwachstellenerkennung und zum Patchen für Forschende und Maintainers bereit
  • Das Unternehmen ruft Entwickler dazu auf, dieses Zeitfenster für stärkere Sicherheit zu nutzen, und plant
    • Zusammenarbeit bei der Schwachstellensuche
    • Entwicklung von Tools zur Klassifizierung von Bug Reports
    • Ausbau automatischer Funktionen für Patch-Vorschläge

2 Kommentare

 
mammal 2026-03-07

Mozilla Foundation Security Advisory 2026-13

Das ist wirklich heftig.

Das scheint erneut ein Fall zu sein, der uns vor Augen führt, wie wichtig strenge Testfälle sind.

 
GN⁺ 2026-03-07
Hacker-News-Kommentare
  • Wer für die Sicherheitswartung eines Open-Source-Projekts verantwortlich ist, sollte Claude Code einmal um ein Security-Audit bitten
    Für Großprojekte wie Firefox mag das schwierig sein, aber bei den meisten Projekten liegen die Token-Kosten nur bei etwa 3 Dollar
    Da Angreifer solche Audits wahrscheinlich ohnehin schon durchführen, ist es nicht länger verantwortungsvoll, es nicht selbst zu tun
    Beim Audit der zentralen Zulip-Codebasis wurde das Modell gebeten, jedes Ergebnis selbst zu überprüfen, wodurch die meisten False Positives herausgefiltert wurden
    Die verbleibenden Probleme verschwanden bei einem erneuten Audit fast vollständig, nachdem Code-Kommentare ergänzt wurden, um die Absicht des Sicherheitsmodells klarer zu machen

    • Diese Art der Nutzung von AI würde ich nicht empfehlen
      „Erledige in ein paar Sekunden, wofür man eine Woche braucht“ ist realistisch nicht möglich
      Die Ergebnisse sehen plausibel aus, können aber von der Realität abweichen
      Man ist weniger enttäuscht, wenn man AI wie einen Praktikanten behandelt — würdest du einem Praktikanten das Security-Audit eines riesigen Programms überlassen?
    • Ich frage mich, ob es einen längeren Text zu Best Practices für AI-Security-Audits gibt
      In manchen Fällen funktioniert es sehr gut, in anderen ist es völlig nutzlos
      Der Unterschied scheint letztlich von der Qualität des Context Engineering und des Test Harness abzuhängen
      Auch dieser Fall war interessant, aber ich hätte mir konkretere Erklärungen gewünscht
  • Ich habe selbst kürzlich ein Projekt als Open Source veröffentlicht, und ein Reddit-Nutzer hat mit Claude ein vollständiges Security-Audit durchgeführt und dabei 15 Schwachstellen gefunden
    Darunter FTS-Injection, LIKE-Wildcard-Injection, fehlende API-Authentifizierung und mangelnder Datenschutz — ich hatte vieles übersehen
    Überraschend war, wie systematisch das Ergebnis war — mit Einstufung nach Schweregrad, Angabe von Dateipfaden und Zeilennummern sowie Hinweisen auf Abweichungen zwischen Dokumentation und tatsächlichem Code
    Besonders nützlich war die Analyse der „Differenz zwischen Spezifikation und Realität
    Der eigentliche Wert von LLM-Security-Audits liegt nicht darin, neue Zero-Days zu finden, sondern darin, repetitive und kleinteilige Prüfungen zu übernehmen, die Menschen aus Bequemlichkeit oft auslassen

  • Nicht viele verstehen die Komplexität von Schwachstellen in Browsern wie Firefox
    Schon die bloße Eskalation eines einfachen UAF zu Wasm-Shellcode kann mehrere Tage dauern
    Das Wettrennen um AI-Fähigkeiten im Cyberbereich ist bisher noch relativ ruhig, aber das dürfte sich noch dieses Jahr ändern
    Ich habe wie Anthropic versucht, Claude eine VM und einen Verifier zu geben und um Exploit-Generierung zu bitten, und in der kctf-eval-Umgebung funktionierte das ziemlich gut
    Unklar bleibt allerdings, was das Modell tatsächlich „versteht“ oder ob es nur anhand von Belohnungssignalen imitierend reagiert

  • Interessant ist, dass Mozilla das Security Advisory aktualisiert hat
    Ich hatte mich gefragt, wer in einem Release 22 Schwachstellen gefunden hat, und jetzt ist das endlich klar

    • „Use After Free“ wird immer wieder erwähnt, aber es fehlt an einer konkreten Erklärung, welche Auswirkungen solche Schwachstellen tatsächlich haben können
      Wenn es nur darum geht, eine Datei abzulegen, ist das keine große Bedrohung, aber das Abgreifen von Sitzungsdaten wäre deutlich interessanter
    • Ich sehe viele bekannte Namen
  • Ich finde es seltsam, dass die konkreten Details der Bugs nicht erwähnt werden
    Ich würde gern wissen, ob es nur Randfälle sind oder tatsächlich bedeutende Probleme
    LLMs finden vertraute Fehlermuster gut, aber das bedeutet nicht immer, dass diese wichtig sind

  • Meine Erfahrungen mit AI-Agenten waren gemischt
    Für die Erweiterung der Testabdeckung, das Einrichten von Fuzz-Tests und das Aufsetzen statischer Analysewerkzeuge waren sie nützlich
    Gleichzeitig behaupteten sie manchmal, etwas sei „sehr sicher“, obwohl in Wirklichkeit gar keine Sicherheitsgrenze vorhanden war
    Lokale Bugs erkennen sie gut, aber komplexe Schwachstellen, die erst durch das Zusammenspiel mehrerer Funktionen entstehen, finden sie fast nie
    Deshalb müssen Sicherheitsbehauptungen des Modells immer überprüft werden

    • [Mozilla-Mitarbeiter] Ich stimme zu, dass LLMs oft falschliegen
      Der Wert dieses Ansatzes liegt darin, verifizierbare Testfälle zu liefern
      Das ist viel effizienter als ein reiner Analysebericht
      Früher stimmte die Aussage, dass nur „lokale Bugs“ gut gefunden werden, aber durch das agentische SDK hat sich die Lage verändert
    • Wenn man AI mit dem Schließen von Coverage-Lücken beauftragt, entstehen viele sinnlose Tests
      Wenn die Coverage bereits hoch ist, liegen die verbleibenden Bereiche von Natur aus im schwierigen Teil
    • Klassische statische Analyse beruhte ebenfalls auf Pattern Matching, aber moderne AI-basierte statische Analysewerkzeuge liefern deutlich bessere Ergebnisse
      Teilweise finden sie sogar Schwachstellen in der Business-Logik
    • Eigentlich gelten diese Grenzen auch für reale Entwickler
      Lokale Bugs springen schnell ins Auge, aber unvollständige Sicherheitsgrenzen wirken anfangs oft ausreichend
    • Wer Anthropics red-team-spezialisierte Claude-Version nutzt, hat einen anderen Zugang als normale Anwender
  • Der Grund, warum Anthropic Firefox gewählt hat, ist klar
    Es ist ein weit verbreitetes Open-Source-Projekt, bei dem Sicherheitsprüfung aktiv betrieben wird
    Chromium nutzt Googles Gemini, und Safari hat eine geschlossene Entwicklungskultur, was eine Zusammenarbeit erschwert

    • Firefox ist zwar fast so komplex wie Chromium, aber ein Projekt mit deutlich weniger Ressourcen und deshalb als Experiment besser geeignet
    • Bei Safari wäre ein Blackbox-Angriff nötig gewesen, daher wäre ein Ansatz wie dieser schwierig gewesen
  • Laut dem Anthropic-Artikel funktionierte der von Claude geschriebene Exploit nur in einer Testumgebung
    Denn die Sandbox des echten Browsers war dort deaktiviert
    Die mehrschichtige Verteidigung (Defense in Depth) von Firefox hätte solche Angriffe daher wohl abgeschwächt

    • [Arbeitet bei Anthropic, früher bei Mozilla] Firefox behandelt auch Schwachstellen innerhalb der Sandbox als eigenständige Sicherheitsprobleme
      Chrome verfolgt eine ähnliche Richtlinie
      Relevante Dokumente finden sich unter Security Severity Ratings
    • Es wäre unangemessen, Schwachstellen zu ignorieren, nur weil es eine Sandbox gibt
      Sandbox-Escapes sind ebenfalls möglich, daher müssen alle Bugs behoben werden
    • Auch wenn die Sandbox etwas abfängt, ist das Beheben der Schwachstellen wichtig
      Angreifer können solche teilweisen Zero-Days sammeln und später kombinieren
      Dass diese Bugs nun behoben wurden, ist daher eindeutig ein Sicherheitsgewinn
  • Ich lasse AI-Agenten ebenfalls über Nacht laufen, um Tests schreiben zu lassen, und habe Claude schon einmal formale Verifikation ausprobieren lassen
    Offenbar hat Anthropic einen ähnlichen Ansatz verfolgt
    Als Nächstes plane ich, Prompts zur Automatisierung von Property-Tests und Fuzz-Tests hinzuzufügen

    • Ich frage mich, ob es reale Beispiele für leichtgewichtige formale Verifikation gibt
      Ich dachte bisher, meine Probleme rechtfertigen diesen Aufwand nicht, aber vielleicht ist das eine Fehleinschätzung
  • Irgendwann wird es vermutlich ein automatisiertes Security-Audit-System für wichtige Open-Source-Projekte geben, ähnlich wie Googles OSS-Fuzz
    Anthropic bietet Maintainern bereits kostenlosen Zugang zu Claude an
    Durch LLMs ist zwar auch das Problem entstanden, dass Bug-Bounty-Programme mit falschen Reports überflutet werden, aber aktuelle Modelle sind inzwischen in der Lage, echte Schwachstellen zu unterscheiden
    Wer mit kostenlosen oder günstigen Modellen evaluiert, wird die Qualität zwangsläufig als niedrig empfinden
    Stattdessen könnte man ein Security-Audit-Programm auf Basis hochwertiger LLMs betreiben und so Qualität sicherstellen
    Um Bug-Bounties zu retten, könnte man auch über Teilnahmegebühren oder LLM-basierte Validierung nachdenken

    • Google betreibt bereits ein AI-basiertes Sicherheitsprojekt namens Big Sleep und meldet Schwachstellen in verschiedenen Open-Source-Projekten
      Relevanter Link
    • Ein System, das Bug-Reports automatisch verifiziert, wäre wünschenswert
      Zum Beispiel indem es eine VM startet und ein Agent dort Reproduktionstests ausführt
    • Soweit ich mich erinnere, läuft Anthropics kostenloses Angebot als automatische Verlängerung im 6-Monats-Rhythmus