defineid/trespasserCVE-2026-74970, Umgehung der Fission-Site-Isolation in Firefox WebRender
Dieses Verzeichnis enthält ein ehrliches Reproduktionsgerüst für einen Fission-Site-Isolation-Autorisierungsbypass in Firefox WebRender. Unter Fission besitzt jeder Content-Prozess einen eigenen PipelineId-Namespace, aber der GPU-Prozess-Code, der eine compositable PipelineId registriert, prüfte nie, ob der Namespace der PipelineId zum sendenden Prozess gehörte. Ein kompromittierter Content-Prozess kann daher eine PipelineId im Namespace eines anderen Prozesses registrieren und die Async-Image-Pipeline dieses Origins im gemeinsamen Manager überschreiben.
Alles hier zielt auf einen lokal gebauten Firefox-Tree mit ausschließlich synthetischen Inhalten ab. Es greift niemals ein Live- oder Drittsystem an, kontaktiert es, sondiert es oder referenziert es. Es handelt sich nicht um Remote Code Execution und nicht um Speicherkorruption; das Bedrohungsmodell ist ein bereits kompromittierter Content-Prozess.
Passendes PoC-Repository: https://github.com/defineid/Trespasser
Writeup: writeup-webrender-pipelineid.html in diesem Portfolio.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-74970 |
| Komponente | Core / Graphics: WebRender |
| Klasse | Site-Isolation-Bypass |
| CWE | 862 (Missing Authorization) · 284 (Improper Access Control) |
| Behoben in | Firefox 154 · ESR 153.1 |
| Bug | https://bugzilla.mozilla.org/show_bug.cgi?id=2056558 |
| PoC-Repo | https://github.com/defineid/Trespasser |
Unter Fission weist WebRender jedem Content-Prozess einen eigenen PipelineId-Namespace zu. Die GPU-Prozess-Bridge soll jede Ressource ablehnen, deren Namespace nicht zu dem Prozess gehört, der sie gesendet hat, damit ein Content-Prozess nicht auf die Rendering-Ressourcen eines anderen zugreifen oder diese überschreiben kann.
WebRenderBridgeParent::AddPipelineIdForCompositable, das im GPU-Prozess läuft, validierte die eingehende Pipeline gegen den Root/WebRender-Guard und gegen die eigene Menge registrierter Pipelines dieser Bridge, rief aber nie MatchesNamespace auf der PipelineId auf. Die Image-Key-, Font-Key- und Blob-Key-Pfade in derselben Datei führen alle diese MatchesNamespace-Eigentumsprüfung durch; der PipelineId-Pfad tat es schlicht nicht. RemovePipelineIdForCompositable ist ebenfalls ungeprüft, sodass dieselbe Lücke bei der Namespace-Zugehörigkeit auch beim Entfernen besteht.
Downstream schützt AsyncImagePipelineManager::AddAsyncImagePipeline die Eindeutigkeit einer Pipeline nur mit MOZ_ASSERT, das in Release-Builds zu einem No-Op kompiliert wird. Wenn also eine gefälschte, prozessübergreifende PipelineId den gemeinsamen AsyncImagePipelineManager erreicht, lehnt der Manager das Duplikat nicht ab: Er überschreibt stillschweigend den bestehenden Async-Image-Pipeline-Eintrag des Opfer-Origins.
Verkettet kann ein kompromittierter Content-Prozess A eine PipelineId fälschen, deren Namespace zu Content-Prozess B gehört (ein anderer Origin, unter Fission in einem separaten Prozess), sie auf dem Compositable-Registrierungspfad einreichen und erreichen, dass der GPU-Prozess sie akzeptiert und Bs Image-Pipeline im gemeinsamen Manager überschreibt.
Ein bereits kompromittierter Content-Prozess unter Fission. Es wird angenommen, dass der Angreifer bereits Codeausführung in einem Content-Prozess hat (beispielsweise durch einen separaten Content-Prozess-Bug) und WebRender-IPC-Nachrichten mit vom Angreifer gewählten Feldern senden kann. Dieser Defekt ist die fehlende Autorisierung, die es diesem Prozess ermöglicht, über die Site-Isolation-Grenze hinweg auf die Rendering-Ressourcen eines anderen Origins zuzugreifen.
Dies ist ein Fission-Site-Isolation-Autorisierungsbypass, keine Speicherkorruption. Die Auswirkung ist originübergreifende Rendering-Verwirrung und tabübergreifender Denial of Service. Downstream-Konsumenten sind null-geprüft und referenzgezählt, sodass daraus keine Codeausführung resultiert. Der PoC darf keine Codeausführung behaupten und tut dies auch nicht.
README.md — diese Datei.forge-namespace.patch — ein Research-Patch für einen lokalen Firefox-Baum. Auf der Content-Seite, abgesichert durch XRE_IsContentProcess() und die Umgebungsvariable MOZ_POC_FORGE_WR_NAMESPACE, fälscht er den Namespace der ausgehenden PipelineId. Auf der Parent-Seite des GPU-Prozesses gibt er eine ACCEPTED-Diagnose aus, wenn eine PipelineId aus einem anderen Namespace registriert wird, und zeigt damit, dass die fehlende Prüfung sie durchgelassen hat.poc.html — ein reiner Content-seitiger Testfall: ein WebGL-Canvas (damit eine asynchrone Bild-Pipeline erzeugt wird) plus ein Cross-Origin-Out-of-Process-iframe (damit Fission es in einem separaten Content-Prozess platziert). In einem Stock-Build rendert es normal und tut nichts Beobachtbares.victim.html — der synthetische zweite Origin, den das iframe lädt. Es ist eine triviale, skriptfreie Seite, deren einzige Aufgabe es ist, ein aktives Cross-Origin-Dokument zu sein, damit sie unter Fission in ihrem eigenen Content-Prozess mit ihrem eigenen PipelineId-Namespace landet (der Namespace, auf den eine gefälschte Registrierung abzielen würde).poc-render.png — ein Screenshot von poc.html, geladen im lokalen Stock-Firefox 140.11.0esr. Er zeigt die Testseite beim normalen Rendern: Das WebGL-Canvas zeichnet seinen Frame und das Out-of-Process-iframe lädt victim.html. Er zeigt nur harmloses Rendering. Die Umgehung selbst erfordert den Research-Patch und einen verwundbaren Build und wurde hier nicht ausgelöst (siehe Verifikationsstatus).Diese Schritte sind dafür gedacht, vom Autor gegen einen lokalen Firefox-Checkout ausgeführt zu werden. Nichts davon wurde in dieser Umgebung gegen Firefox ausgeführt (siehe Verifikationsstatus unten).
Checken Sie einen verwundbaren Firefox-Quellbaum aus (vor 154 / vor ESR 153.1) und bestätigen Sie, dass Fission aktiviert ist (fission.autostart = true, der Standard bei aktuellen Builds).
Wenden Sie den Research-Patch vom obersten Verzeichnis des Quellbaums aus an:
patch -p1 < forge-namespace.patch
Der Patch berührt gfx/layers/wr/WebRenderBridgeChild.cpp (Content-Seite,
fälscht den Namespace) und gfx/layers/wr/WebRenderBridgeParent.cpp
(GPU-Prozess-Seite, gibt die AKZEPTIERTE Diagnose aus). Beide Änderungen sind
inert, sofern die Guard-Bedingungen nicht erfüllt sind.
Normal bauen (./mach build).
Dieses Verzeichnis so ausliefern, dass das Out-of-Process-iframe von poc.html
die begleitende victim.html von einer tatsächlich anderen registrierbaren Domain
lädt, sodass Fission das iframe in einen eigenen Content-Prozess verschiebt. Zum Beispiel
python3 -m http.server 8000 --bind :: und das iframe von
http://victim.localtest.me:8000/victim.html laden. Siehe den Inline-Kommentar in
poc.html.
Den Build mit gesetzter Forge-Variable starten und die Testseite laden:
MOZ_POC_FORGE_WR_NAMESPACE=999999 ./mach run --temp-profile poc.html
999999 ist ein willkürlich gewählter Namespace-Wert, der so gewählt wurde, dass er zu keinem realen Prozess gehört; er macht die gefälschte, namespace-übergreifende Registrierung im Log offensichtlich.
Bei einem verwundbaren Build mit angewendetem Patch akzeptiert und registriert der GPU-Prozess-Elternprozess eine PipelineId, deren Namespace zu keinem solchen Prozess gehört, und gibt aus (dies ist die exakte Form, die im Writeup gezeigt wird):
[POC-2056558] ACCEPTED cross-namespace PipelineId:
sender-namespace=4 pipeline-namespace=999999 (should have been rejected)