Google Chrome के 120.0.6099.224 से पहले V8 में सीमा से बाहर मेमोरी एक्सेस

CVE मैपिंग और पैच

• टिप्पणी करने वाले सटीक git diff खोजने की कोशिश करते हैं; कई संभावित commits और bug IDs का उल्लेख होता है, और CVE-2024-0517, -0518, और -0519 के बीच कुछ भ्रम रहता है।
• एक प्रतिभागी नोट करता है कि Chrome के release notes 0519 को सुझाए गए commit से अलग issue number से जोड़ते हैं, इसलिए सटीक मैपिंग अभी भी कुछ हद तक अस्पष्ट है।
• Fedora advisories तीन अलग-अलग V8 CVEs का उल्लेख करते हैं (type confusion, OOB read, OOB write), जो एक ही समय के आसपास कई compiler/runtime समस्याओं का संकेत देते हैं।

प्रभावित संस्करण और उत्पाद

• NVD की CPE सूची Chrome 9 तक प्रभाव दर्शाती है, लेकिन लोग ज़ोर देते हैं कि ये ranges अक्सर unvalidated होती हैं और स्पष्ट रूप से गलत भी हो सकती हैं (उदाहरण: एक WebGPU बग जो WebGPU के अस्तित्व से पहले के संस्करणों को “प्रभावित” बताता है)।
• चूँकि यह बग संभवतः Maglev compiler से संबंधित है, जो लगभग Chrome 114 के आसपास आया था, पुराने Chrome संस्करण (जैसे 60) संभवतः प्रभावित नहीं हैं, हालांकि यह निष्कर्ष पुष्टि की बजाय अनुमान पर आधारित है।
• क्योंकि तीनों CVE V8 में हैं, V8 को embed करने वाली कोई भी चीज़ (Node.js, Electron apps, custom embedders, serverless/edge platforms) जोखिम में हो सकती है यदि वे untrusted या semi-trusted JavaScript चलाती हैं।

Untrusted code, sandboxing, और प्रभाव

• “untrusted code” का अर्थ लेकर बहस होती है:
  • एक विचार: कोई भी कोड जिसका पूरी तरह audit न किया गया हो, untrusted है, इसलिए सामान्य Node dependency stacks भी इसमें आते हैं।
  • दूसरा विचार: यदि आप उसे अपने process में चलाते हैं, तो आप व्यावहारिक रूप से उस पर भरोसा कर रहे हैं; “untrusted” वह कोड है जिसके malicious होने की आशंका हो और जिसे sandbox करना ज़रूरी है।
• Browsers और कई apps hostile input के लिए V8 को एक sandbox की तरह बहुत अधिक उपयोग करते हैं; इस तरह के bugs उस धारणा को कमजोर करते हैं।
• exploit writeup (0517 के लिए) Wasm-आधारित chain के माध्यम से V8/“Ubercage” sandbox के भीतर शक्तिशाली read/write हासिल करता है; public chain में Chrome का बाहरी OS-level sandbox टूटा हुआ नहीं दिखता।
• कुछ लोग नोट करते हैं कि sandbox-केवल code execution भी platform details के आधार पर users की पहचान उजागर कर सकता है या उन्हें deanonymize कर सकता है।

JIT, fuzzing, और भाषा सुरक्षा

• कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि fuzzing, चाहे Chrome/V8 में कितना भी भारी क्यों न हो, stochastic है और वर्षों तक गहरे bugs को miss कर सकती है।
• अन्य लोग तर्क देते हैं कि JIT engines implementation language चाहे जो हो, फिर भी miscompile कर सकते हैं; memory-safe languages इस श्रेणी को पूरी तरह नहीं हटाते, हालांकि वे अन्य raw memory errors को कम करते हैं।
• वैकल्पिक डिज़ाइनों पर चर्चा होती है: safer interpreters, JIT को disable करना (जो major browsers में समर्थित है), और manual IR manipulation को कम करने के लिए higher-level JIT frameworks (जैसे Graal/Truffle-style)।
• सहमति: कोई नहीं जानता कि बड़े, high-performance JITs और browsers को zero security bugs के साथ कैसे बनाया जाए; memory-safe languages मदद करते हैं लेकिन पूर्ण समाधान नहीं हैं।

Threat models और operational risk

• “bored five-year-olds” (कम-मेहनत वाले attackers) और nation-states के बीच अंतर किया जाता है; दूसरे अक्सर मज़बूत defenses के बावजूद सफल हो सकते हैं।
• वास्तविक दुनिया के अधिकांश breaches अभी भी साधारण गलतियों (unpatched software, खराब passwords) से होते हैं, न कि नए V8 0-days से; इसलिए अधिकतर संगठनों के लिए समय पर updates ज़्यादा महत्वपूर्ण हैं।
• ऐसे bugs को governments को बेचने वाले exploit brokers और unpatched browsers के पैमाने को लेकर चिंता व्यक्त की जाती है।

Legacy systems और दीर्घकालिक exposure

• Windows 7 पर Chrome version 109 पर अटका हुआ है; इन systems को नए V8 bugs के लिए fixes नहीं मिलेंगे।
• कुछ लोग तर्क देते हैं कि जो कोई नेटवर्क पर Windows 7 चला रहा है, उसे “security की परवाह नहीं”; दूसरे जवाब देते हैं कि isolated, firewalled Windows 7 machine मुख्यतः अपने browser के माध्यम से exposed हो सकती है।
• Windows 7/8/XP के अभी भी non-trivial market share रखने की टिप्पणियाँ एक बड़े, स्थायी रूप से vulnerable install base की चिंता को बढ़ाती हैं।