Eine unscheinbare, aber gefährliche Speicherfehler trat sechs Monate lang unbemerkt in Firefox auf – und betraf mehr als 180 Millionen Nutzer –, bevor Sicherheitsforscher ihn entdeckten.
Die Sicherheitslücke ermöglichte es Angreifern, den Speicher zu beschädigen und über manipulierte WebAssembly-Payloads potenziell beliebigen Code auszuführen.
„Das autonome KI-System von Aisle entdeckte diese subtile Sicherheitslücke durch eine Grenzbedingung während unserer umfassenden Untersuchung der WebAssembly-Sicherheit. Dabei wurden erhebliche Risiken für die Speichersicherheit von rund 180 Millionen Firefox-Nutzern sichtbar“, sagte Stanislav Fort, Gründer und leitender Wissenschaftler bei AISLE.
Er fügte hinzu: „Mozilla stellte schnell einen Fix bereit. Moderne Browser gehören zu den sichersten und am sorgfältigsten entwickelten Plattformen überhaupt. Dieser Fund unterstreicht, wie wichtig kontinuierliche, KI-gestützte Sicherheitsforschung ist, um sie für Nutzer weltweit sicher zu halten.“
Der versteckte Codefehler, der Firefox-Nutzer gefährdete
Im Zentrum der Sicherheitslücke (CVE-2025-13016) steht ein subtiler Fehler bei der Zeigerarithmetik in der WebAssembly-Garbage-Collection-(GC-)Implementierung von Firefox, genauer in der StableWasmArrayObjectElements-Klasse. Nicht übereinstimmende Zeigertypen führten dort zum fehlerhaften Kopieren eingebetteter Array-Daten.
Der anfällige Code verwendete byteadressierte Zeiger (uint8_t*), um die zu kopierende Datenmenge zu berechnen, führte den Kopiervorgang jedoch in einen Puffer vom Typ uint16_t durch.
Wurde das Template für 16-Bit-Werte instanziiert, interpretierte std::copy() den bytebasierten Bereich als Anzahl typisierter Elemente und nicht als Anzahl von Bytes.
Dadurch erhielt ein Puffer, der für N 16-Bit-Elemente vorgesehen war, stattdessen 2N Elemente. Das ließ den Stapelspeicher überlaufen und beschädigte angrenzende Datenstrukturen.
Verschärft wurde das Problem durch einen zweiten Fehler: Der Kopiervorgang las nicht aus der korrekten Speicherposition.
Statt den dafür vorgesehenen Zeiger auf den Datenbereich des Arrays zu verwenden, griff der Code auf inlineStorage() zurück – eine Position, die mit internen Objektmetadaten beginnt.
Das bedeutet, dass es sich bei den ersten in den Puffer kopierten Bytes überhaupt nicht um Array-Inhalte handelte, sondern um strukturelle Informationen über das WebAssembly-Objekt selbst. Dies sorgt für zusätzliche Unberechenbarkeit und erhöht die Wahrscheinlichkeit, dass sich der beschädigte Speicher bei einem Angriff ausnutzen lässt.
Diese Voraussetzungen benötigen Angreifer zur Ausnutzung der Firefox-Sicherheitslücke
Nicht jeder Ausführungspfad in Firefox berührt die fehlerhafte Routine, weshalb die Sicherheitslücke so lange unentdeckt blieb.
Das Problem wird nur ausgelöst, wenn Firefox auf einen langsameren, GC-aktivierten Fallback-Pfad zur Verarbeitung von WebAssembly-Arrays zurückfällt – und zwar während der Umwandlung dieser Arrays in Zeichenketten.
In einem typischen Ablauf manipuliert WebAssembly-Code zunächst ein Array, etwa ein char16_t-Array.
Anschließend versucht Firefox, dieses Array mithilfe einer schnellen Operation, die Garbage Collection vermeidet, in eine Zeichenkette umzuwandeln.
Führen bestimmte Bedingungen – meist Speicherdruck – dazu, dass dieser schnelle Pfad fehlschlägt, wechselt der Browser jedoch zu einer Fallback-Routine, in der GC zulässig ist.
In diesem Fallback ruft Firefox den Konstruktor von StableWasmArrayObjectElements auf, der den fehlerhaften Kopiervorgang ausführt und letztlich den Stapel zum Überlaufen bringt sowie angrenzenden Speicher beschädigt.
In realistischen Angriffsszenarien könnte ein Angreifer gezielt ein bösartiges WebAssembly-Modul erstellen, um diesen Ablauf zu seinen Gunsten zu manipulieren.
Durch Arrays bestimmter Größe, das absichtliche Herbeiführen von Speicherdruck, um die Garbage Collection zu erzwingen, und wiederholtes Auslösen der Umwandlung von Arrays in Zeichenketten könnte ein Angreifer Firefox zuverlässig in den anfälligen Fallback-Pfad zwingen.
Dadurch entstünde eine kontrollierte Umgebung, in der sich die resultierende Speicherbeschädigung auf ein ausgewähltes Ziel auf dem Stapel richten ließe.
Maßnahmen zur Eindämmung der Firefox-Sicherheitslücke
Organisationen können ihr Risiko durch die Sicherheitslücke verringern, indem sie die neuesten Firefox-Patches einspielen und zusätzliche Defense-in-Depth-Maßnahmen umsetzen, um den Zugriff von Angreifern zu begrenzen, eine potenzielle Ausnutzung einzudämmen und die Browsersicherheit zu stärken.
- Priorisieren Sie die Bereitstellung von Firefox 145 oder höher (oder ESR 140,5+) auf allen Systemen und überprüfen Sie organisationsweit die Einhaltung der Versionsvorgaben.
- Setzen Sie Richtlinien für die Browserverwaltung in Unternehmen durch , um risikoreiche Funktionen einzuschränken, die Sandbox-Kontrollen zu verschärfen und kritische Sicherheitskonfigurationen zu sperren.
- Deaktivieren Sie WebAssembly vorübergehend in Umgebungen, in denen nicht sofort gepatcht werden kann, insbesondere auf Endpunkten mit hoher Gefährdung.
- Überwachen Sie Browserprotokolle, EDR-Signale und Absturzanalysen auf WebAssembly-bezogene Speicherfehler oder ungewöhnliches Verhalten von Firefox-Prozessen.
- Setzen Sie Abwehrmaßnahmen auf Netzwerkebene ein – etwa DNS-Filter, sichere Web-Gateways und Tools zur Domain-Reputationsprüfung –, um bösartige oder verdächtige Webinhalte zu blockieren.
- Setzen Sie Browser-Isolation ein oder segmentieren Sie risikoreiche Browseraktivitäten, um Bedrohungen durch Nutzer einzudämmen, die regelmäßig auf nicht vertrauenswürdige Websites zugreifen.
- Stärken Sie die Abwehr von Endpunkten und Betriebssystemen durch die Durchsetzung von Einstellungen zur Exploit-Abwehr, Anwendungs-Sandboxing und strengen Zugriffskontrollen nach dem Prinzip der geringsten Berechtigung.
Zusammengenommen tragen diese Maßnahmen dazu bei, die allgemeine Cyberresilienz zu stärken.
Die größeren Lehren für die Sicherheit aus CVE-2025-13016
Diese Sicherheitslücke verdeutlicht die wachsenden Risiken, die entstehen, wenn Browser zunehmend komplexe Low-Level-Technologien wie WebAssembly GC einsetzen.
Selbst geringfügige Fehler in speicherunsicheren Sprachen wie C++ können schwerwiegende Sicherheitslücken hervorbringen, die traditionelle Code-Reviews und Regressionstests überstehen – wie dieser Fehler zeigt, der mit einem eigenen Test ausgeliefert wurde und dennoch sechs Monate lang unentdeckt blieb.
Der Vorfall unterstreicht außerdem, wie wichtig autonome Analysetools sind, um subtile Speicherprobleme zu erkennen, die herkömmliche Qualitätssicherungsprozesse häufig übersehen.
Da WebAssembly immer stärker in moderne Webanwendungen eingebettet wird, müssen sowohl Browserhersteller als auch Unternehmen in bessere Schutzmaßnahmen investieren, um Low-Level-Speicherfehler zu verhindern und zu erkennen.
Die Dauer dieser unentdeckten Sicherheitslücke zeigt, warum die Pflege eines ausgereiften Patch-Management-Programms für den Schutz vor Browserrisiken entscheidend ist.