{"id":1192,"date":"2026-02-19T12:35:52","date_gmt":"2026-02-19T12:35:52","guid":{"rendered":"https:\/\/netguide.io\/news\/?p=1192"},"modified":"2026-02-19T12:52:05","modified_gmt":"2026-02-19T12:52:05","slug":"fataler-tippfehler-wie-ein-einzelnes-zeichen-zur-rce-lucke-in-firefox-fuhrte","status":"publish","type":"post","link":"https:\/\/netguide.io\/news\/de\/2026\/02\/19\/fataler-tippfehler-wie-ein-einzelnes-zeichen-zur-rce-lucke-in-firefox-fuhrte\/","title":{"rendered":"Fataler Tippfehler: Wie ein einzelnes Zeichen zur RCE-L\u00fccke in Firefox f\u00fchrte"},"content":{"rendered":"\n

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\u00fccke erlaubte es Angreifern, Schadcode innerhalb des Renderer-Prozesses des Browsers auszuf\u00fchren.<\/strong><\/p>\n\n\n\n

Die Schwachstelle wurde im Rahmen einer Analyse des Quellcodes f\u00fcr eine kommende “Capture The Flag” (CTF)-Challenge im Februar 2026 entdeckt. Betroffen war die WebAssembly (Wasm)-Komponente von SpiderMonkey, genauer gesagt die Speicherverwaltung f\u00fcr Garbage-Collected (GC) Arrays.<\/p>\n\n\n\n

Der “Guilty Commit”: Ein &<\/code> zu viel<\/h3>\n\n\n\n

Die Ursache der Sicherheitsl\u00fccke liegt in einem Refactoring-Prozess der Metadaten von Wasm-Arrays. In der betroffenen Datei js\/src\/wasm\/WasmGcObject.cpp<\/code> passierte dem Entwickler ein klassischer logischer Fehler bei der Bit-Manipulation:<\/p>\n\n\n\n

\n

Der fehlerhafte Codeabschnitt:<\/strong><\/p>\n\n\n\n

C++<\/p>\n\n\n\n

\/\/ Erwartet wurde eine Bitweise-ODER-Verkn\u00fcpfung (|), um ein Flag zu setzen.\noolHeaderOld->word = uintptr_t(oolHeaderNew) & 1; \/\/ Der Fehler: '&' statt '|'\n<\/code><\/pre>\n<\/blockquote>\n\n\n\n
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 (&<\/code>), dass der Wert fast immer auf 0<\/strong> 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\u00fcpfung mit 1 ergibt somit zwangsl\u00e4ufig das Ergebnis 0.<\/p>\n\n\n\n
Inline vs. Out-of-line: Das Missverst\u00e4ndnis im Speicher<\/h3>\n\n\n\n
Um die Schwere des Fehlers zu verstehen, muss man die Speicherstruktur von Wasm-Arrays in Firefox betrachten. SpiderMonkey nutzt zwei Strategien:<\/p>\n\n\n\n
    \n
  1. Inline (IL):<\/strong> Daten werden direkt hinter dem Objektkopf gespeichert (f\u00fcr kleine Arrays).<\/li>\n\n\n\n
  2. Out-of-line (OOL):<\/strong> Das Objekt zeigt auf einen separaten Speicherblock (f\u00fcr gro\u00dfe Arrays).<\/li>\n<\/ol>\n\n\n\n
    Durch den Tippfehler hielt die Engine ein verschobenes, gro\u00dfes Array (OOL) f\u00e4lschlicherweise f\u00fcr ein Inline-Array, da die Markierung (das gesetzte Bit im Header) fehlte.<\/p>\n\n\n\n
    Von der Fehlermeldung zur Remote Code Execution<\/h3>\n\n\n\n
    Der Forscher konnte demonstrieren, dass dieser Fehler zu einer sogenannten Use-After-Free (UAF)<\/strong>-Situation f\u00fchrt. Wenn der Garbage Collector (GC) den Speicher bereinigt, wird der alte Speicherbereich freigegeben, w\u00e4hrend der JIT-Compiler (Ion) aufgrund des falschen Headers weiterhin versucht, auf die alte, nun ung\u00fcltige Adresse zuzugreifen.<\/p>\n\n\n\n
    Durch gezieltes “Heap Spraying” – das kontrollierte \u00dcberfluten des Arbeitsspeichers mit eigenen Daten – gelang es Erge, den freigegebenen Speicherplatz mit b\u00f6sartigen Werten zu f\u00fcllen. Dies erm\u00f6glichte:<\/p>\n\n\n\n