CVE-2026-74970 · PipelineId नेमस्पेस जाँच के अभाव में Firefox Fission साइट-आइसोलेशन बायपास

यह निर्देशिका Firefox WebRender में Fission साइट-आइसोलेशन प्राधिकरण बायपास के लिए एक ईमानदार पुनरुत्पादन स्कैफ़ोल्ड रखती है। Fission के अंतर्गत प्रत्येक कंटेंट प्रोसेस का अपना अलग PipelineId नेमस्पेस होता है, लेकिन GPU-प्रोसेस कोड जो किसी कंपोज़िटेबल PipelineId को पंजीकृत करता है, उसने कभी यह जाँच नहीं की कि PipelineId का नेमस्पेस भेजने वाले प्रोसेस का ही है। इसलिए एक समझौता किया गया कंटेंट प्रोसेस किसी अन्य प्रोसेस के नेमस्पेस में एक PipelineId पंजीकृत कर सकता है और साझा मैनेजर में उस ओरिजिन की async इमेज पाइपलाइन को अधिलेखित कर सकता है।

यहाँ सब कुछ केवल सिंथेटिक कंटेंट के साथ स्थानीय रूप से बनाए गए Firefox ट्री को लक्षित करता है। यह कभी भी किसी लाइव या तृतीय-पक्ष सिस्टम पर हमला, संपर्क, प्रोब या संदर्भ नहीं करता। यह रिमोट कोड एक्ज़ीक्यूशन नहीं है और न ही मेमोरी करप्शन है; खतरे का मॉडल एक पहले से समझौता किया गया कंटेंट प्रोसेस है।

मिलता-जुलता PoC रिपॉज़िटरी: https://github.com/defineid/Trespasser राइटअप: इस पोर्टफ़ोलियो में writeup-webrender-pipelineid.html।

तथ्य

फ़ील्ड	मान
CVE	CVE-2026-74970
घटक	Core / Graphics: WebRender
वर्ग	साइट-आइसोलेशन बायपास
CWE	862 (अनुपस्थित प्राधिकरण) · 284 (अनुचित एक्सेस नियंत्रण)
में ठीक किया गया	Firefox 154 · ESR 153.1
बग	https://bugzilla.mozilla.org/show_bug.cgi?id=2056558
PoC रिपॉज़िटरी	https://github.com/defineid/Trespasser

तंत्र

Fission के अंतर्गत, WebRender प्रत्येक कंटेंट प्रोसेस को उसका अपना PipelineId नेमस्पेस प्रदान करता है। GPU-प्रोसेस ब्रिज से अपेक्षा है कि वह किसी भी ऐसे संसाधन को अस्वीकार करे जिसका नेमस्पेस उसे भेजने वाले प्रोसेस का न हो, ताकि एक कंटेंट प्रोसेस किसी अन्य के रेंडरिंग संसाधनों को संबोधित या अधिलेखित न कर सके।

WebRenderBridgeParent::AddPipelineIdForCompositable, जो GPU प्रोसेस में चलता है, आने वाली पाइपलाइन को रूट/WebRender गार्ड के विरुद्ध और इस ब्रिज के अपने पंजीकृत पाइपलाइनों के सेट के विरुद्ध सत्यापित करता था, लेकिन उसने PipelineId पर कभी MatchesNamespace को कॉल नहीं किया। उसी फ़ाइल में image-key, font-key और blob-key पथ सभी वह MatchesNamespace स्वामित्व जाँच करते हैं; PipelineId पथ ने बस ऐसा नहीं किया। RemovePipelineIdForCompositable भी इसी तरह बिना जाँच के है, इसलिए हटाने पर भी वही नेमस्पेस-स्वामित्व वाला छेद मौजूद है।

डाउनस्ट्रीम में, AsyncImagePipelineManager::AddAsyncImagePipeline किसी पाइपलाइन की विशिष्टता की रक्षा केवल MOZ_ASSERT से करता है, जो रिलीज़ बिल्ड्स में no-op में कंपाइल हो जाता है। इसलिए जब एक जाली, क्रॉस-नेमस्पेस PipelineId साझा AsyncImagePipelineManager तक पहुँचता है, तो मैनेजर डुप्लिकेट को अस्वीकार नहीं करता: यह चुपचाप विक्टिम ओरिजिन की मौजूदा async इमेज पाइपलाइन प्रविष्टि को अधिलेखित कर देता है।

श्रृंखलाबद्ध रूप से, एक समझौता किया गया कंटेंट प्रोसेस A एक ऐसा PipelineId जाली रूप से बना सकता है जिसका नेमस्पेस कंटेंट प्रोसेस B का है (एक भिन्न ओरिजिन, Fission के अंतर्गत एक अलग प्रोसेस में), उसे कंपोज़िटेबल-पंजीकरण पथ पर सबमिट कर सकता है, और GPU प्रोसेस उसे स्वीकार करके साझा मैनेजर में B की इमेज पाइपलाइन को क्लॉबर कर सकता है।

खतरे का मॉडल

Fission के अंतर्गत एक पहले से समझौता किया गया कंटेंट प्रोसेस। यह माना गया है कि हमलावर के पास पहले से ही एक कंटेंट प्रोसेस में कोड एक्ज़ीक्यूशन है (उदाहरण के लिए किसी अलग कंटेंट-प्रोसेस बग के माध्यम से) और वह हमलावर-चयनित फ़ील्ड्स के साथ WebRender IPC संदेश भेज सकता है। यह दोष वह अनुपस्थित प्राधिकरण है जो उस प्रोसेस को साइट-आइसोलेशन सीमा को पार करके किसी अन्य ओरिजिन के रेंडरिंग संसाधनों तक पहुँचने देता है।

यह एक Fission साइट-आइसोलेशन प्राधिकरण बायपास है, मेमोरी करप्शन नहीं। इसका प्रभाव क्रॉस-ओरिजिन रेंडरिंग भ्रम और क्रॉस-टैब डिनायल ऑफ़ सर्विस है। डाउनस्ट्रीम उपभोक्ता null-गार्डेड और रेफ़रेंस-काउंटेड हैं, इसलिए यह कोड एक्ज़ीक्यूशन नहीं देता। PoC को कोड एक्ज़ीक्यूशन का दावा नहीं करना चाहिए और यह नहीं करता।

इस निर्देशिका में क्या है

• README.md — यह फ़ाइल।
• forge-namespace.patch — एक स्थानीय Firefox ट्री के लिए एक शोध पैच। कंटेंट पक्ष पर, XRE_IsContentProcess() और पर्यावरण चर MOZ_POC_FORGE_WR_NAMESPACE द्वारा सुरक्षित, यह आउटगोइंग PipelineId का namespace गढ़ता (forge) है। GPU-प्रोसेस पैरेंट पक्ष पर यह एक ACCEPTED डायग्नोस्टिक प्रिंट करता है जब एक क्रॉस-namespace PipelineId पंजीकृत होता है, यह प्रदर्शित करते हुए कि अनुपस्थित जाँच ने इसे पास होने दिया।
• poc.html — एक नंगा कंटेंट-पक्ष परीक्षण केस: एक WebGL कैनवास (ताकि एक async इमेज पाइपलाइन बने) और एक क्रॉस-ओरिजिन आउट-ऑफ-प्रोसेस iframe (ताकि Fission इसे एक अलग कंटेंट प्रोसेस में रखे)। स्टॉक बिल्ड पर यह सामान्य रूप से रेंडर होता है और कुछ भी अवलोकनीय नहीं करता।
• victim.html — वह सिंथेटिक दूसरा ओरिजिन जिसे iframe लोड करता है। यह एक तुच्छ, स्क्रिप्ट-रहित पेज है जिसका एकमात्र काम एक जीवंत क्रॉस-ओरिजिन दस्तावेज़ होना है, ताकि Fission के अंतर्गत यह अपने स्वयं के कंटेंट प्रोसेस में अपने स्वयं के PipelineId namespace के साथ पहुँचे (वह namespace जिसे एक forged पंजीकरण लक्षित करेगा)।
• poc-render.png — स्थानीय स्टॉक Firefox 140.11.0esr में लोड किए गए poc.html का एक स्क्रीनशॉट। यह परीक्षण पेज को सामान्य रूप से रेंडर होते हुए दिखाता है: WebGL कैनवास अपना फ़्रेम बनाता है और आउट-ऑफ-प्रोसेस iframe victim.html लोड करता है। यह केवल सौम्य रेंडरिंग दिखाता है। बायपास के लिए स्वयं शोध पैच और एक भेद्य बिल्ड की आवश्यकता होती है और इसे यहाँ नहीं ट्रिगर किया गया था (सत्यापन स्थिति देखें)।

स्थानीय बिल्ड के विरुद्ध कैसे लागू करें और चलाएँ

ये चरण लेखक द्वारा एक स्थानीय Firefox चेकआउट के विरुद्ध निष्पादित किए जाने के लिए हैं। इस परिवेश में Firefox के विरुद्ध यहाँ कुछ भी निष्पादित नहीं किया गया था (नीचे सत्यापन स्थिति देखें)।

1. एक भेद्य Firefox स्रोत ट्री चेकआउट करें (154 / ESR 153.1 से पहले) और पुष्टि करें कि Fission सक्षम है (fission.autostart = true, हाल के बिल्ड पर डिफ़ॉल्ट)।

2. स्रोत ट्री के शीर्ष से शोध पैच लागू करें:

   patch -p1 < forge-namespace.patch
   

   पैच gfx/layers/wr/WebRenderBridgeChild.cpp (कंटेंट साइड, नेमस्पेस को फोर्ज करता है) और gfx/layers/wr/WebRenderBridgeParent.cpp (GPU-प्रोसेस साइड, ACCEPTED डायग्नोस्टिक प्रिंट करता है) को छूता है। दोनों परिवर्तन तब तक निष्क्रिय हैं जब तक गार्ड शर्तें पूरी न हों।

3. सामान्य रूप से बिल्ड करें (./mach build)।

4. इस डायरेक्टरी को सर्व करें ताकि poc.html का आउट-ऑफ-प्रोसेस iframe सहयोगी victim.html को वास्तव में भिन्न रजिस्ट्रेबल डोमेन से लोड करे, जिससे Fission iframe को उसके अपने कंटेंट प्रोसेस में रखे। उदाहरण के लिए, python3 -m http.server 8000 --bind :: और iframe को http://victim.localtest.me:8000/victim.html से लोड करें। poc.html में इनलाइन टिप्पणी देखें।

5. बिल्ड को forge वेरिएबल सेट करके लॉन्च करें और टेस्ट पेज लोड करें:

   MOZ_POC_FORGE_WR_NAMESPACE=999999 ./mach run --temp-profile poc.html
   

   999999 एक मनमाना namespace मान है जिसे इस तरह चुना गया है कि यह किसी वास्तविक प्रक्रिया से संबंधित न हो; यह लॉग में नकली, क्रॉस-namespace पंजीकरण को स्पष्ट बनाता है।

अपेक्षित स्वीकृत-क्रॉस-namespace लॉग पंक्ति

पैच लागू किए गए एक vulnerable बिल्ड पर, GPU-प्रक्रिया का parent एक ऐसे PipelineId को स्वीकार और पंजीकृत करता है जिसका namespace किसी ऐसी प्रक्रिया से संबंधित नहीं है, और प्रिंट करता है (यह वही सटीक रूप है जो writeup में दिखाया गया है):

[POC-2056558] ACCEPTED cross-namespace PipelineId:
  sender-namespace=4  pipeline-namespace=999999  (should have been rejected)

sender-namespace वह namespace है जो वैध रूप से भेजने वाली content प्रक्रिया के स्वामित्व में है; pipeline-namespace वह जाली (forged) मान है। ये दो भिन्न मान, साथ ही यह तथ्य कि पंजीकरण स्वीकार कर लिया गया, पूरी बात का सार है: वह स्वामित्व जाँच, जो इसे अस्वीकार कर देती, अनुपस्थित है।

एक ठीक किए गए बिल्ड (154 / ESR 153.1 और उसके बाद) पर, वही संदेश IPC_FAIL के साथ अस्वीकार कर दिया जाता है और ऐसी कोई ACCEPTED पंक्ति प्रिंट नहीं होती, क्योंकि PipelineId पथ अब MatchesNamespace को लागू करता है।

एक-पंक्ति का समाधान

PipelineId पथ पर वही namespace-स्वामित्व जाँच लागू करें जो resource-key पथ पहले से उपयोग करते हैं:

if (!MatchesNamespace(aPipelineId)) {
  return IPC_FAIL(this, "PipelineId namespace does not belong to the sending process");
}