Mountain View/London – In der Welt der Softwareentwicklung kann ein einziges Zeichen den Unterschied zwischen Sicherheit und totaler Kompromittierung bedeuten. Der Sicherheitsforscher Erge dokumentierte nun, wie ein simpler Tippfehler in SpiderMonkey – der JavaScript-Engine von Firefox – eine kritische Schwachstelle (Remote Code Execution, RCE) verursachte. Die Lücke erlaubte es Angreifern, Schadcode innerhalb des Renderer-Prozesses des Browsers auszuführen.
Die Schwachstelle wurde im Rahmen einer Analyse des Quellcodes für eine kommende „Capture The Flag“ (CTF)-Challenge im Februar 2026 entdeckt. Betroffen war die WebAssembly (Wasm)-Komponente von SpiderMonkey, genauer gesagt die Speicherverwaltung für Garbage-Collected (GC) Arrays.
Der „Guilty Commit“: Ein & zu viel
Die Ursache der Sicherheitslücke liegt in einem Refactoring-Prozess der Metadaten von Wasm-Arrays. In der betroffenen Datei js/src/wasm/WasmGcObject.cpp passierte dem Entwickler ein klassischer logischer Fehler bei der Bit-Manipulation:
Der fehlerhafte Codeabschnitt:
C++
// Erwartet wurde eine Bitweise-ODER-Verknüpfung (|), um ein Flag zu setzen. oolHeaderOld->word = uintptr_t(oolHeaderNew) & 1; // Der Fehler: '&' statt '|'
Anstatt die Adresse des neuen Speicherbereichs mit dem gesetzten „Least Significant Bit“ (LSB) zu speichern, um einen sogenannten „Forwarding Pointer“ zu markieren, bewirkte das bitweise UND (&), dass der Wert fast immer auf 0 gesetzt wurde. Da Pointer in modernen Systemen normalerweise an 8-Byte-Grenzen ausgerichtet sind, ist das letzte Bit einer Adresse immer Null – eine UND-Verknüpfung mit 1 ergibt somit zwangsläufig das Ergebnis 0.
Inline vs. Out-of-line: Das Missverständnis im Speicher
Um die Schwere des Fehlers zu verstehen, muss man die Speicherstruktur von Wasm-Arrays in Firefox betrachten. SpiderMonkey nutzt zwei Strategien:
- Inline (IL): Daten werden direkt hinter dem Objektkopf gespeichert (für kleine Arrays).
- Out-of-line (OOL): Das Objekt zeigt auf einen separaten Speicherblock (für große Arrays).
Durch den Tippfehler hielt die Engine ein verschobenes, großes Array (OOL) fälschlicherweise für ein Inline-Array, da die Markierung (das gesetzte Bit im Header) fehlte.
Von der Fehlermeldung zur Remote Code Execution
Der Forscher konnte demonstrieren, dass dieser Fehler zu einer sogenannten Use-After-Free (UAF)-Situation führt. Wenn der Garbage Collector (GC) den Speicher bereinigt, wird der alte Speicherbereich freigegeben, während der JIT-Compiler (Ion) aufgrund des falschen Headers weiterhin versucht, auf die alte, nun ungültige Adresse zuzugreifen.
Durch gezieltes „Heap Spraying“ – das kontrollierte Überfluten des Arbeitsspeichers mit eigenen Daten – gelang es Erge, den freigegebenen Speicherplatz mit bösartigen Werten zu füllen. Dies ermöglichte:
- ASLR-Bypass: Das Auslesen von Speicheradressen, um die Schutzmechanismen des Betriebssystems zu umgehen.
- Arbitrary Write: Das Schreiben von Daten an beliebige Stellen im Speicher.
- RCE: Das Kapern des Befehlszeigers (RIP), um schließlich eine Shell (
/bin/sh) zu starten.
Schnelle Reaktion von Mozilla
Glücklicherweise wurde die Schwachstelle sehr früh im Entwicklungszyklus entdeckt. Der Fehler wurde am 19. Januar 2026 eingeführt und erreichte lediglich die Firefox 149 Nightly-Version.
Die Timeline der Offenlegung:
- 19. Januar 2026: Einführung des Fehlers durch einen Commit.
- 03. Februar 2026: Zeitgleiche Meldung durch Erge und einen weiteren anonymen Forscher.
- 09. Februar 2026: Offizieller Fix durch Mozilla.
- 11. Februar 2026: Auszahlung der Bug-Bounty, die zwischen den beiden Reportern aufgeteilt wurde.
Dank der schnellen Reaktion des Firefox-Security-Teams gelangte der Fehler nie in eine stabile Release-Version, sodass normale Endnutzer zu keinem Zeitpunkt gefährdet waren. Der Fall unterstreicht jedoch einmal mehr, wie fragil moderne Hochleistungs-Software sein kann, wenn ein einzelner Tastendruck die gesamte Sicherheitsarchitektur aushebelt.
Quelle: https://kqx.io/post/firefox0day/
