मेल्टडाउन/स्पेक्टर

Surma

खास जानकारी

Project Zero ने 3 जनवरी को, आधुनिक सीपीयू में मौजूद ऐसी कमजोरियों का पता लगाया है जिनका इस्तेमाल, प्रोसेस किसी भी मेमोरी को पढ़ने के लिए कर सकती है. इसमें ऐसी मेमोरी भी शामिल है जो उस प्रोसेस से जुड़ी नहीं है. इन कमजोरियों को Spectre और Meltdown नाम दिया गया है. वेब को सुरक्षित रखने के लिए, Chrome क्या कर रहा है और वेब डेवलपर को अपनी साइटों के लिए क्या करना चाहिए?

कम शब्दों में कहा जाए, तो डॉक्टर

वेब ब्राउज़ करने वाले उपयोगकर्ता के तौर पर, आपको यह पक्का करना चाहिए कि आपका ऑपरेटिंग सिस्टम और ब्राउज़र अप-टू-डेट हो. इसके अलावा, Chrome के उपयोगकर्ता साइट आइसोलेशन की सुविधा चालू कर सकते हैं.

अगर आप वेब डेवलपर हैं, तो Chrome टीम की सलाह है:

• जहां भी हो सके, कुकी को रेंडर करने की प्रोसेस की मेमोरी में जाने से रोकें. इसके लिए, SameSite और HTTPOnly कुकी एट्रिब्यूट का इस्तेमाल करें. साथ ही, document.cookie से पढ़ने से बचें.
• पक्का करें कि आपके MIME टाइप सही हों. साथ ही, उपयोगकर्ता के हिसाब से या संवेदनशील कॉन्टेंट वाले किसी भी यूआरएल के लिए X-Content-Type-Options: nosniff हेडर तय करें. इससे, साइट अलगाव की सुविधा चालू करने वाले उपयोगकर्ताओं के लिए, क्रॉस-ऑरिजिन रीड ब्लॉकिंग का ज़्यादा से ज़्यादा फ़ायदा लिया जा सकता है.
• साइट आइसोलेशन की सुविधा चालू करें. अगर इससे आपकी साइट पर कोई समस्या आती है, तो Chrome की टीम को बताएं.

अगर आपको यह जानना है कि यह तरीका क्यों मददगार है, तो आगे पढ़ें!

जोखिम

इन जोखिम की संभावनाओं के बारे में कई तरह की जानकारी दी गई है. इसलिए, हम एक और जानकारी नहीं जोड़ेंगे. अगर आपको यह जानना है कि इन कमजोरियों का इस्तेमाल कैसे किया जा सकता है, तो हमारा सुझाव है कि आप Google Cloud टीम के मेरे साथियों की ब्लॉग पोस्ट पढ़ें.

Meltdown और Spectre, दोनों ही किसी प्रोसेस को ऐसी मेमोरी पढ़ने की अनुमति देते हैं जिसे पढ़ने की अनुमति नहीं है. कभी-कभी, अलग-अलग साइटों के कई दस्तावेज़ों के लिए, Chrome में एक ही प्रोसेस का इस्तेमाल किया जा सकता है. ऐसा तब हो सकता है, जब किसी एक पेज को window.open, <a href="..." target="_blank"> या iframes का इस्तेमाल करके खोला गया हो. अगर किसी वेबसाइट में उपयोगकर्ता से जुड़ा डेटा है, तो हो सकता है कि कोई दूसरी साइट, उपयोगकर्ता के डेटा को पढ़ने के लिए इन नई कमजोरियों का इस्तेमाल करे.

जोखिम कम करने के तरीके

इस खतरे को कम करने के लिए, Chrome और V8 इंजीनियरिंग टीम कई तरह से काम कर रही है.

साइट आइसोलेशन

Spectre का इस्तेमाल करके, संवेदनशील डेटा को हैकर के कंट्रोल वाले कोड के साथ शेयर करने से रोककर, इसकी वजह से होने वाले नुकसान को काफ़ी कम किया जा सकता है. Chrome की टीम, इस सुविधा पर काम कर रही है, जिसे “साइट आइसोलेशन” कहा जाता है:

साइट आइसोलेशन की सुविधा को फ़िलहाल डिफ़ॉल्ट रूप से चालू नहीं किया गया है, क्योंकि इसमें कुछ समस्याएं हैं. साथ ही, Chrome की टीम इस सुविधा को ज़्यादा से ज़्यादा फ़ील्ड टेस्ट करना चाहती है. अगर आप वेब डेवलपर हैं, तो आपको साइट आइसोलेशन की सुविधा चालू करनी चाहिए और यह देखना चाहिए कि आपकी साइट काम करती रहेगी या नहीं. अगर आपको अभी ऑप्ट-इन करना है, तो chrome://flags#enable-site-per-process को चालू करें. अगर आपको कोई ऐसी साइट मिलती है जो काम नहीं कर रही है, तो कृपया बग की शिकायत करके हमारी मदद करें. साथ ही, यह भी बताएं कि आपने साइट अलगाव की सुविधा चालू की हुई है.

क्रॉस-साइट दस्तावेज़ ब्लॉकिंग

भले ही, सभी क्रॉस-साइट पेजों को अलग-अलग प्रोसेस में रखा गया हो, फिर भी पेज कुछ क्रॉस-साइट सब-रिसॉर्स का अनुरोध कर सकते हैं. जैसे, इमेज और JavaScript. साइट अलगाव में “क्रॉस-साइट दस्तावेज़ ब्लॉकिंग” सुविधा शामिल होती है. इससे, संवेदनशील जानकारी को लीक होने से रोका जा सकता है. इस सुविधा से यह तय किया जा सकता है कि रेंडरर प्रोसेस को कौनसे नेटवर्क रिस्पॉन्स डिलीवर किए जाएं.

कोई वेबसाइट, सर्वर से दो तरह के डेटा का अनुरोध कर सकती है: “दस्तावेज़” और “संसाधन”. यहां दस्तावेज़, एचटीएमएल, एक्सएमएल, जेएसओएन, और टेक्स्ट फ़ाइलें हैं. कोई वेबसाइट, अपने डोमेन या अनुमति देने वाले सीओआरएस हेडर वाले अन्य डोमेन से दस्तावेज़ पा सकती है. रिसॉर्स में इमेज, JavaScript, सीएसएस, और फ़ॉन्ट जैसी चीज़ें शामिल होती हैं. किसी भी साइट से संसाधन शामिल किए जा सकते हैं.

क्रॉस-साइट दस्तावेज़ ब्लॉक करने की नीति, किसी प्रोसेस को दूसरे ऑरिजिन से “दस्तावेज़” पाने से रोकती है. ऐसा तब होता है, जब:

1. उनका MIME टाइप, एचटीएमएल, एक्सएमएल, JSON या टेक्स्ट/सामान्य टेक्स्ट हो, और
2. उनमें X-Content-Type-Options: nosniff एचटीटीपी रिस्पॉन्स हेडर है या कॉन्टेंट का तुरंत विश्लेषण (“स्निफ़िंग”) करके यह पुष्टि की गई है कि टाइप सही है
3. सीओआरएस, दस्तावेज़ को ऐक्सेस करने की अनुमति साफ़ तौर पर नहीं देता

इस नीति के तहत ब्लॉक किए गए दस्तावेज़ों को प्रोसेस के लिए खाली के तौर पर दिखाया जाता है. हालांकि, अनुरोध अब भी बैकग्राउंड में किया जाता है.

उदाहरण के लिए: मान लें कि कोई हमलावर <img> टैग बनाता है, जिसमें <img src="https://yourbank.com/balance.json"> जैसे संवेदनशील डेटा वाली JSON फ़ाइल शामिल होती है. साइट अलगाव के बिना, JSON फ़ाइल का कॉन्टेंट रेंडरर प्रोसेस की मेमोरी में चला जाएगा. इस दौरान, रेंडरर को पता चलता है कि यह मान्य इमेज फ़ॉर्मैट नहीं है और वह इमेज रेंडर नहीं करता. हालांकि, Spectre की मदद से, अब उस मेमोरी को पढ़ा जा सकता है. क्रॉस-साइट दस्तावेज़ ब्लॉकिंग की सुविधा, इस फ़ाइल के कॉन्टेंट को कभी भी उस प्रोसेस की मेमोरी में शामिल होने से रोक देगी जिसमें रेंडरर चल रहा है. ऐसा इसलिए, क्योंकि क्रॉस-साइट दस्तावेज़ ब्लॉकिंग की सुविधा, MIME टाइप को ब्लॉक कर देती है.

उपयोगकर्ता मेट्रिक के मुताबिक, ऐसी कई JavaScript और सीएसएस फ़ाइलें हैं जिन्हें text/html या text/plain MIME टाइप के साथ डिलीवर किया जाता है. गलती से दस्तावेज़ के तौर पर मार्क किए गए संसाधनों को ब्लॉक करने से बचने के लिए, Chrome रिस्पॉन्स को स्निफ़ करने की कोशिश करता है, ताकि यह पक्का किया जा सके कि MIME टाइप सही है. यह स्निफ़िंग पूरी तरह से सही नहीं है. इसलिए, अगर आपको लगता है कि आपने अपनी वेबसाइट पर सही Content-Type हेडर सेट किए हैं, तो Chrome टीम का सुझाव है कि आप अपने सभी रिस्पॉन्स में X-Content-Type-Options: nosniff हेडर जोड़ें.

अगर आपको अलग-अलग साइटों के दस्तावेज़ों को ब्लॉक करने की सुविधा आज़मानी है, तो ऊपर बताए गए तरीके से साइट अलगाव के लिए ऑप्ट-इन करें.

SameSite कुकी

आइए, ऊपर दिए गए उदाहरण पर वापस जाएं: <img src="https://yourbank.com/balance.json">. यह सुविधा सिर्फ़ तब काम करती है, जब yourbank.com ने ऐसी कुकी सेव की हो जो उपयोगकर्ता को अपने-आप लॉग इन कर देती हो. आम तौर पर, कुकी उन सभी अनुरोधों के लिए भेजी जाती हैं जो कुकी सेट करने वाली वेबसाइट को किए जाते हैं. भले ही, अनुरोध <img> टैग का इस्तेमाल करके तीसरे पक्ष ने किया हो. SameSite कुकी एक नया एट्रिब्यूट है, जो बताता है कि कुकी को सिर्फ़ उस अनुरोध से अटैच किया जाना चाहिए जो उसी साइट से शुरू होता है. इसलिए, इसका नाम SameSite है. माफ़ करें, इस लेख को लिखने के समय, सिर्फ़ Chrome और Firefox 58 और उसके बाद के वर्शन पर इस एट्रिब्यूट का इस्तेमाल किया जा सकता है.

HTTPOnly और document.cookie

अगर आपकी साइट की कुकी का इस्तेमाल सिर्फ़ सर्वर साइड पर किया जाता है, न कि क्लाइंट JavaScript के ज़रिए, तो कुकी के डेटा को रेंडर करने की प्रोसेस में शामिल होने से रोका जा सकता है. HTTPOnly कुकी एट्रिब्यूट सेट किया जा सकता है. इससे, Chrome जैसे काम करने वाले ब्राउज़र पर, क्लाइंट साइड स्क्रिप्ट की मदद से कुकी को ऐक्सेस करने से रोका जा सकता है. अगर HTTPOnly सेट करना मुमकिन नहीं है, तो document.cookie को तब तक न पढ़कर, रेंडर की गई प्रोसेस में लोड होने वाली कुकी के डेटा के एक्सपोज़र को सीमित किया जा सकता है, जब तक कि ज़रूरी न हो.

rel="noopener" का इस्तेमाल करके बाहरी लिंक खोलना

target="_blank" का इस्तेमाल करके किसी दूसरे पेज से लिंक करने पर, खुले हुए पेज के पास आपके window ऑब्जेक्ट का ऐक्सेस होता है. साथ ही, वह आपके पेज को किसी दूसरे यूआरएल पर ले जा सकता है. साइट अलगाव के बिना, वह आपके पेज की तरह ही काम करेगा. अपने पेज को बेहतर तरीके से सुरक्षित रखने के लिए, नई विंडो में खुलने वाले बाहरी पेजों के लिंक में हमेशा rel="noopener" की जानकारी होनी चाहिए.

हाई रिज़ॉल्यूशन वाले टाइमर

Meltdown या Spectre का फ़ायदा पाने के लिए, हमलावर को यह मेज़र करना होगा कि मेमोरी से किसी वैल्यू को पढ़ने में कितना समय लगता है. इसके लिए, भरोसेमंद और सटीक टाइमर की ज़रूरत होती है.

वेब प्लैटफ़ॉर्म पर एक एपीआई उपलब्ध है, जो performance.now() के हिसाब से सटीक है. इस समस्या को कम करने के लिए, सभी बड़े ब्राउज़र ने performance.now() के रिज़ॉल्यूशन को कम कर दिया है, ताकि हमले करना मुश्किल हो जाए.

SharedArrayBuffer का इस्तेमाल करके भी, हाई रिज़ॉल्यूशन वाला टाइमर पाया जा सकता है. काउंटर बढ़ाने के लिए, एक वर्कर्स को बफ़र का इस्तेमाल करना होता है. मुख्य थ्रेड, इस काउंटर को पढ़ता है और इसका इस्तेमाल टाइमर के तौर पर करता है. फ़िलहाल, ब्राउज़र ने SharedArrayBuffer को तब तक बंद करने का फ़ैसला लिया है, जब तक कि इस समस्या को कम करने के अन्य तरीके लागू नहीं हो जाते.

V8

Spectre का फ़ायदा उठाने के लिए, सीपीयू निर्देशों का एक खास क्रम होना ज़रूरी है. V8 टीम ने कॉन्सेप्ट के लिए, पहले से मौजूद अटैक के सबूतों को कम करने के लिए उपाय लागू किए हैं. साथ ही, वह अपने ऑप्टिमाइज़िंग कंपाइलर, TurboFan में बदलाव करने पर काम कर रही है. इससे, इन अटैक के ट्रिगर होने पर भी, जनरेट किया गया कोड सुरक्षित रहता है. हालांकि, कोड जनरेशन में किए गए इन बदलावों की वजह से, परफ़ॉर्मेंस पर असर पड़ सकता है.

वेब को सुरक्षित रखना

Spectre और Meltdown की खोज और उनके असर को लेकर काफ़ी अनिश्चितता रही है. हमें उम्मीद है कि इस लेख से आपको यह जानकारी मिली होगी कि वेब प्लैटफ़ॉर्म को सुरक्षित रखने के लिए, Chrome और V8 की टीमें क्या कर रही हैं. साथ ही, यह भी पता चला होगा कि वेब डेवलपर, सुरक्षा से जुड़ी मौजूदा सुविधाओं का इस्तेमाल करके कैसे मदद कर सकते हैं. अगर आपका कोई सवाल है, तो बेझिझक Twitter पर हमसे संपर्क करें.