क्रोम सुरक्षा कमजोरी रिपोर्ट के लिए 250,000 डॉलर का इनाम तय

• Chrome के VRP बाउंटी पैनल ने हाल ही में एक सुरक्षा कमजोरी रिपोर्ट के लिए $250,000 का इनाम तय किया
• रिपोर्ट की गई कमजोरी ipcz कंपोनेंट की बग है, जिसमें रेंडरर ब्राउज़र प्रोसेस का handle क्लोन करके सैंडबॉक्स से बाहर निकलने की संभावना बनती है
• संबंधित मुद्दा Chromium के Internals>Mojo>Core क्षेत्र में उठाया गया था
• इस कमजोरी से उपयोगकर्ताओं की सुरक्षा पर खतरा बढ़ सकता है
• इस मुद्दे को कोड बदलकर पैच करने की दिशा में काम चल रहा है

---

मुख्य मुद्दों का संक्षिप्त अवलोकन

• हाल ही में Chromium प्रोजेक्ट में एक अत्यंत गंभीर सुरक्षा कमजोरी रिपोर्ट की गई है
• यह कमजोरी ipcz कंपोनेंट की खामी के कारण संभव हुई है, जिसमें सैंडबॉक्स में रहना चाहिए ऐसा रेंडरर ब्राउज़र प्रोसेस का handle क्लोन करके सुरक्षा अलगाव वातावरण से बाहर निकल सकता है
• ऐसा व्यवहार मूलतः ब्राउज़र सैंडबॉक्स आर्किटेक्चर के लिए एक खतरा है

Chrome VRP इनाम निर्णय और महत्व

• Chrome Vulnerability Reward Program (पुरस्कार कार्यक्रम) पैनल ने इस रिपोर्ट पर $250,000 के भुगतान का निर्णय लिया
• यह निर्णय इस कमजोरी की गंभीरता, खोजने की कठिनाई और संभावित प्रभाव को दर्शाता है
• यह प्रमुख सुरक्षा खामियों पर सक्रिय रूप से बग रिपोर्टिंग को प्रोत्साहित करने की प्रतिबद्धता का उदाहरण है

आंतरिक मुद्दा निपटान

• इस मुद्दे को Internals>Mojo>Core और Internals>Mojo श्रेणियों में संभाला जा रहा है
• कई संबंधित कोड बदलाव की आवश्यकता है, जिसमें कुछ Gerrit कोड कमिट भी शामिल हैं
• डिजाइन दस्तावेज़ की समीक्षा जैसी औपचारिक समीक्षा प्रक्रियाएँ भी चल रही हैं

पैच और प्रभाव

• संबंधित समस्या कोड संशोधन प्रक्रिया के जरिए पैच करने के लिए प्रगति पर है
• यह मुद्दा Chromium के कई रिलीज़ माइलस्टोन को प्रभावित कर रहा है, और सिक्योरिटी अपडेट की प्राथमिकता बहुत उच्च है
• यह बग उपयोगकर्ता सिस्टम की सुरक्षा परतों को कमजोर करने का जोखिम पैदा कर सकता है

संबंधित तथ्य और सिस्टम प्रतिक्रिया

• इस मुद्दे के तहत IRM (Incident Response Management) रिकॉर्ड भी तैयार किया गया है
• इस बग का विवरण ऑटो-जनरेटेड कोड बदलाव, संबंधित सुरक्षा मुद्दे, डिजाइन समीक्षा, रिलीज़ प्रबंधन जैसी विभिन्न आंतरिक प्रणालियों में ट्रैक और नियंत्रित तरीके से एक्सेस किया जा रहा है
• समुदाय और उपयोगकर्ताओं के लिए त्वरित तथा प्रभावी सिक्योरिटी पैच रिलीज़ और सूचना जारी करना आवश्यक है

[GN⁺]

Hacker News टिप्पणियाँ

• उसका मानना है कि उसके पास सबसे ज्यादा उपयोग किए जाने वाले browser के लिए एक काफी विश्वसनीय exploit था, और अगर वह उसे ब्लैक मार्केट में बेचता तो टैक्स बचाकर कहीं ज्यादा कमा सकता था।
  EDR (Endpoint Detection and Response) जैसी security tools की व्यापक deployment के कारण अब exploit को जल्दी catch किया जाना संभव है, लेकिन कुछ authoritarian सरकारों की intelligence agencies शायद ऐसे पत्रकाराना हैक (journalism-like hacking) में भी निवेश करना उचित समझें।

  • वाकई क्या ब्लैक मार्केट में टैक्स बचाकर ज्यादा मिल जाता, और भरोसेमंद अपराधी को कहीं से खोजा जा सकता है—यह बड़ा सवाल है।
    इसमें transaction को anonymous और trust-based तरीके से करना पड़ता है; पैसे मिलते हुए भी blackmail जैसे अतिरिक्त risk बनते हैं, और बड़ी रकम छुपाना आसान नहीं होता, इसलिए exploit को पूरी तरह safely बेचने का तरीका समझ नहीं आता।
    ऊपर से इतनी कमाई होने पर ब्लॉग पर पोस्ट नहीं कर पाते, researchers या recruiters को अपना नाम नहीं बता पाते, जिससे career और reputation को नुकसान हो सकता है।
  • यह भी नहीं कि ब्लैक मार्केट में बेचने से पैसे स्वतः टैक्स-फ्री बन जाते हैं—कई बार उलटा होता है।
    जब कभी बैंक अकाउंट में बड़ी राशि आएगी, निगरानी का risk होता ही है; इसलिए टैक्स की तरह money laundering भी करनी पड़ती है और laundering service की फीस अलग देनी पड़ती है, यानी practically टैक्स दो बार भरना पड़ता है।
    क्रिप्टो में भी ऐसा ही है क्योंकि वहाँ mining/ownership का proof दिखाना पड़ता है, इसलिए कोई आसान हल नहीं।
  • सभी लोग सिर्फ पैसे से तुलना कर रहे हैं, जबकि बेहतर है कि थोड़ा नैतिक नजरिए से भी देखें।
    संभावित मुनाफ़े के कारण लाखों लोगों को नुकसान पहुंचाने के अवसर सैकड़ों अपराधियों को देने का जोखिम बनता है—इसे गंभीरता से सोचना होगा।
  • हमेशा नहीं कि ब्लैक मार्केट में टैक्स बचाकर ज्यादा मिल जाए।
    Chrome में sandbox escape या उसके bypass के लिए official तौर पर $200,000 तक की bounty मिल सकती है—इस announcement की 72वीं slide share की गई थी।
    यही presentation GitHub पर भी उपलब्ध है, लेकिन अभी GitHub down है, इसलिए अतिरिक्त तौर पर यह reddit लिंक share किया गया।
  • ऐसे vulnerabilities बहुत कम उदाहरणों में आते हैं जहाँ liquid market मौजूद होता है।
    खासकर ऐसे bugs को कई बार री-सैल भी किया जा सकता है, क्योंकि ऐसे dedicated कंपनियाँ भी हैं जो इन्हें राष्ट्रीय स्तर पर अलग-अलग intelligence या law enforcement agencies को बेचती हैं।

• Chrome में sandbox escape और high-quality रिपोर्ट के लिए reward $250,000 है।
  Mozilla इसी प्रकार की vulnerability पर सिर्फ $20,000 देती है—official rules और Mozilla bug bounty लिंक के साथ तुलना की गई।

  • Wikipedia के हिसाब से यह रकम (Mozilla के net profit के मुकाबले) 0.012% बनती है।
    comment thread में किसी ने कहा कि ऐसे comparison की शुरुआत सही नहीं, लेकिन अगर percentage में देखें तो Google के मुकाबले लगभग 50 गुना ज्यादा है—इसलिए पर्याप्त बड़ा।
    (पहले प्रतिशत गणना गलत थी; बाद में ठीक करके बताया कि 0.012% ही सही है—$20,000, यानी $157,000,000 का 0.012%, यानी Google के percentage से 50x ज़्यादा।)
  • Chrome users की संख्या Firefox users से करीब 15–20 गुना अधिक होने के कारण, ब्लैक मार्केट में भी bug की कीमत इसी अनुपात में अधिक बनती है।
    Safari में शायद अधिक affluent और कम सुरक्षा-चिंतित users होने के कारण कीमत और भी ज्यादा हो सकती है।
  • दोनों कंपनियों की फ़ाइनेंशियल स्थिति देखकर स्पष्ट है कि Google, Mozilla से कहीं ज्यादा कमाता है।
  • किसी ने मज़ाक में कहा कि अगर HN में हर कोई Mozilla का CEO बनकर जो चाहे बोलने लगे तो मज़ा आए—
    अंदर ऑफिस में सब लोग अपने पसंदीदा policy point (privacy, web standards को मजबूत करना, speed सुधारना, bug bounty reward बढ़ाना आदि) पर जोश से बात करते दिखते हैं, जबकि पीछे से स्लो-मोशन में एक गिरती हुई red revenue line वाला cartoon चल रहा हो।
  • gray market में भी Firefox vulnerabilities की demand और supply दोनों कारणों से reward काफी कम हो जाता है।

• “इस हफ्ते सिर्फ देखने के लिए issue पांच दिन पहले खुला रखा” जैसी लाइन देखकर किसी ने Defcon वाला सलाम-जैसा comment जोड़ा।

• संदर्भ के लिए, यह exploit Rust में लिखा है इसलिए block हो जाने वाला नहीं; यह मुख्यतः logic/timing issue था।

• पूछताछ उठी कि sandbox escape bug वास्तव में होता क्या है, और क्या browser में 'renderer', 'native API', 'sandbox' न समझने वालों के लिए आसान explainer उपलब्ध है?

  • पहले चरण में किसी JavaScript engine bug आदि से renderer process पर control ले लिया जाता है, लेकिन उस चरण में भी renderer sandbox के अंदर ही रहता है।
    इस पोस्ट की bug दूसरा चरण यानी sandbox escape के लिए थी।
    सार्वजनिक patch.diff पहले से compromise हुए renderer process को simulate करने के लिए patch के तौर पर ही दिखाया गया था।

• reward से जुड़ा comment लिंक यहाँ है।

• “इतना बड़ा पैसा ज़िंदगी बदल दे” — यह सुनकर प्रतिक्रिया आई कि ऐसा reward देखना खुशी की बात है।

  • Denmark में जहाँ मैं रहता हूँ, टैक्स हट भी जाए तो भी इसमें शायद सिर्फ एक studio apartment नहीं खरीदी जा सकती।
    जब मुझे पहली बार $240,000 का bonus मिला था, तब लगा था life बदल जाएगी; लेकिन करीब $100,000 टैक्स में चला गया।
    फिर $20,000 car पर खर्च करने के बाद खास कुछ बचा नहीं।
    LA/SF/NYC के हिसाब से तो यह पर्याप्त नहीं था और startup शुरू करने के लिए भी नहीं।
    अगर कॉलेज छात्र की तरह रहता तो शायद 2–3 साल निकल जाते, पर मैं तब 34 साल का था, इसलिए वापस उस उम्र में नहीं जा सकता था।
    नतीजा यह कि सच में बड़ा बदलाव नहीं आया।
    हाँ, इतनी बड़ी राशि मिलना निश्चित ही अच्छी बात थी, लेकिन मेरे अनुभव में life वैसी नहीं बदली जितनी मैं चाहता था।
    यह 25 साल पहले की बात है; अभी इन तीन शहरों में $1,000,000 (after-tax $600,000) भी life बदलने लायक नहीं लगता।
    कम से कम home deposit या बच्चों की college fees में मदद मिलती, पर वह वास्तविक freedom महसूस नहीं हुई जिसकी उम्मीद थी।
  • यह रकम कहाँ रहती है, इससे मतलब बदलता है।
    developed देशों में $250,000 को life-changing कहना मुश्किल है—इसे बस कुछ समय तक चिंता कम करने वाला धन कहा जा सकता है।
    टैक्स के बाद तो घर खरीदना भी संभव नहीं होता।

• बड़े scale के इस project में bug ढूंढना सच में outstanding लगता है, जैसे भूसे में सुई खोज लेना।

  • बड़े और complex project में code ज्यादा होता है, इसलिए कई बार छोटे project से उलटा bug खोजने में अपेक्षाकृत आसान हो सकता है।
    लेकिन sandbox escape जैसी गंभीर vulnerability को Google की aggressive bounty policy के कारण पहले से कई लोगों ने manual और automated analysis (fuzzer tools समेत) कर रखी है, इसलिए उसे पकड़ना बेहद कठिन होना स्वाभाविक है।
    2014 में मैंने Chrome में गलती से एक bug पकड़ लिया था—bug खोजने की intent नहीं थी, बस JS code लिखते समय issue दिखा—रिपोर्ट करने पर Google ने $1,500 दिए, और अनुभव बताया कि इसमें करीब 30 मिनट लगे।
    संबंधित लिंक
  • दूसरी तरफ, बड़ा project होने से components के बीच अजीब interactions ज्यादा होने की वजह से खोज आसान भी हो सकती है—यह भी एक नजरिया है।
    फोकस हमेशा critical security boundary पर होता है (यहाँ renderer और broker communication), यानी edge cases में घुसकर देखना।
    Google ऐसे प्रकार के bugs को reward देता है, इसलिए detection पर बड़ा payout मिलता है।
    फिर भी सच यह है कि इसे खोज पाना अभी भी बहुत उच्च कौशल मांगता है।

• reward payout की speed भी प्रभावित करने वाली थी—लगभग 4 हफ्तों में bounty मिल गई; जबकि कई कंपनियों में केवल bug report स्वीकार होने में ही कई महीने लग जाते हैं।

• अगर DOJ Chrome को विभाजित करने और नई ownership संरचना लाने में सफल होता है, तो क्या इस स्तर की bug bounty लंबे समय तक टिक पाएगी—इस पर शक व्यक्त किया गया।