3 जनवरी, 2018 को, Google प्रोजेक्ट ज़ीरो और अन्य ने कमजोरियों की एक नई श्रेणी के पहले तीन का खुलासा किया जो सट्टा निष्पादन प्रोसेसर को प्रभावित करते हैं। उन्हें स्पेक्टर (1 और 2) और मेल्टडाउन कहा जाता था। सट्टा सीपीयू निष्पादन तंत्र का उपयोग करते हुए, एक हमलावर अस्थायी रूप से स्पष्ट और अंतर्निहित सॉफ्टवेयर सुरक्षा जांच दोनों को बायपास कर सकता है जो प्रोग्राम को मेमोरी में दुर्गम डेटा को पढ़ने से रोकता है। जबकि सट्टा निष्पादन को सूक्ष्म स्तर के एक हिस्से के रूप में डिज़ाइन किया गया था, वास्तुशिल्प स्तर पर अदृश्य, सावधानीपूर्वक डिज़ाइन किए गए प्रोग्राम एक अटकलबाजी ब्लॉक में दुर्गम जानकारी पढ़ सकते हैं और इसे साइड चैनलों के माध्यम से प्रकट कर सकते हैं, जैसे कि प्रोग्राम के निष्पादन का समय।

जब यह दिखाया गया कि जावास्क्रिप्ट का उपयोग करके स्पेक्टर हमले संभव हैं, तो V8 टीम ने समस्या को हल करने में भाग लिया। हमने एक आपातकालीन प्रतिक्रिया टीम का गठन किया और अन्य Google टीमों, हमारे अन्य ब्राउज़र साझेदारों और हार्डवेयर भागीदारों के साथ मिलकर काम किया। उनके साथ मिलकर, हमने दोनों आक्रामक अनुसंधान (अवधारणा को साबित करने के लिए हमलावर मॉड्यूल का निर्माण) और रक्षात्मक (संभावित हमलों को कम करने) का संचालन किया।

स्पेक्टर हमले में दो भाग होते हैं:

• सीपीयू की अव्यक्त स्थिति में अन्यथा दुर्गम डेटा की कमी । सभी ज्ञात स्पेक्टेर हमले सीपीयू कैश के लिए दुर्गम डेटा के बिट्स को स्थानांतरित करने के लिए अटकलों का उपयोग करते हैं।
  
• अप्राप्य डेटा को पुनर्स्थापित करने के लिए एक छिपे हुए राज्य को प्राप्त करना। इसके लिए, एक हमलावर को पर्याप्त सटीकता की घड़ी की आवश्यकता होती है। (आश्चर्यजनक रूप से कम सटीकता, विशेष रूप से धार थ्रेशोल्ड जैसे तरीकों के साथ - एक चयनित रूपरेखा के साथ तुलना में)।

सैद्धांतिक रूप से, यह हमले के दो घटकों में से किसी को ब्लॉक करने के लिए पर्याप्त होगा। चूंकि हम नहीं जानते हैं कि उनमें से किसी को पूरी तरह से कैसे अवरुद्ध किया जाए, इसलिए हमने ऐसे मिटिगेशन विकसित और तैनात किए हैं जो सीपीयू कैश और मिटिगेशन में लीक होने वाली सूचनाओं की मात्रा को काफी कम कर देते हैं जिससे छिपी हुई स्थिति को बहाल करना मुश्किल हो जाता है।

उच्च परिशुद्धता टाइमर

छोटे राज्य के परिवर्तन जो सट्टेबाजी के निष्पादन के बाद बने रहते हैं, लगभग छोटे, अस्थायी रूप से छोटे, अस्थायी अंतर - एक सेकंड के एक अरबवें क्रम के होते हैं। व्यक्तिगत रूप से ऐसे मतभेदों का सीधे पता लगाने के लिए, हमलावर को एक उच्च-सटीक टाइमर की आवश्यकता होती है। प्रोसेसर ऐसे टाइमर पेश करते हैं, लेकिन वेब प्लेटफ़ॉर्म उन्हें सेट नहीं करता है। performance.now() पर सबसे सटीक टाइमर .now performance.now() वेब प्लेटफॉर्म में कई माइक्रोसेकंड का एक संकल्प था, जिसे शुरू में इस उद्देश्य के लिए अनुपयुक्त माना गया था। हालांकि, दो साल पहले, सूक्ष्म अनुसंधान में विशेषज्ञता वाले एक शोध समूह ने एक वेब प्लेटफॉर्म पर टाइमर पर एक लेख प्रकाशित किया था। उन्होंने निष्कर्ष निकाला कि एक साथ परस्पर साझा की गई मेमोरी और विभिन्न रिज़ॉल्यूशन रिकवरी विधियां नैनोकॉन्ड के नीचे और भी उच्च रिज़ॉल्यूशन के टाइमर के निर्माण की अनुमति देती हैं। इस तरह की टाइमर L1 कैश की व्यक्तिगत हिट और मिसेज का पता लगाने के लिए सटीक हैं। यह वह है जो आमतौर पर स्पेक्टर हमलों में जानकारी पर कब्जा करने के लिए उपयोग किया जाता है।

समय की सुरक्षा

समय में छोटे अंतर का पता लगाने की क्षमता को बाधित करने के लिए, ब्राउज़र डेवलपर्स ने एक बहुपक्षीय दृष्टिकोण चुना है। सभी ब्राउज़रों में, performance.now() क्षमता को कम किया गया था। performance.now() क्रोम में 5 माइक्रोसेकंड से 100 तक घटाया गया था और संकल्प की बहाली को रोकने के लिए यादृच्छिक घबराना शुरू किया गया था। सभी ब्राउज़रों के डेवलपर्स के बीच विचार-विमर्श के बाद, हमने एक अभूतपूर्व कदम उठाने का फैसला किया: एक नैनोसेकंड टाइमर के निर्माण को रोकने के लिए तुरंत और सभी ब्राउज़रों में SharedArrayBuffer API को निष्क्रिय कर SharedArrayBuffer ।

सुदृढ़ीकरण

हमारे आक्रामक अनुसंधान की शुरुआत में, यह स्पष्ट हो गया कि अकेले ही टाइमर शमन पर्याप्त नहीं हैं। कारणों में से एक यह है कि एक हमलावर बस अपना कोड बार-बार चला सकता है ताकि संचयी समय का अंतर एक हिट या कैश मिस से बहुत अधिक हो। हम विश्वसनीय "गैजेट" का निर्माण करने में सक्षम थे जो एक समय में कई कैश लाइनों का उपयोग करते हैं, पूरी कैश क्षमता तक, जो 600 माइक्रोसेकंड तक का समय अंतर देता है। बाद में, हमने मनमाने ढंग से प्रवर्धन विधियों की खोज की जो कैश क्षमता द्वारा सीमित नहीं हैं। इस तरह के प्रवर्धन के तरीके गुप्त डेटा को पढ़ने के बार-बार किए जाने वाले प्रयासों पर आधारित हैं।

JIT संरक्षण

स्पेक्टर का उपयोग करने वाले दुर्गम डेटा को पढ़ने के लिए, एक हमलावर सीपीयू को सट्टा रूप से निष्पादित कोड के लिए मजबूर करता है जो सामान्य रूप से दुर्गम डेटा को पढ़ता है और उन्हें कैश में डालता है। दो पक्षों से संरक्षण पर विचार किया जा सकता है:

1. सट्टा कोड निष्पादन को रोकें।
   
2. सट्टा पाइपलाइन से दुर्गम डेटा को पढ़ने से रोकना।

हमने प्रत्येक महत्वपूर्ण सशर्त शाखा पर इंटेल की LFENCE जैसे अटकलों को रोकने के लिए अनुशंसित निर्देशों को सम्मिलित करते हुए पहले विकल्प के साथ प्रयोग किया और अप्रत्यक्ष शाखाओं के लिए रेटपोलिन का उपयोग किया। दुर्भाग्य से, इस तरह के भारी उपद्रव उत्पादकता (ऑक्टेन बेंचमार्क पर 2-3x मंदी) को काफी कम कर देते हैं। इसके बजाय, हमने शमन के अनुक्रमों को सम्मिलित करके दूसरा दृष्टिकोण लिया जो संवेदनशील डेटा को अनुचित अटकलों के कारण पढ़ने से रोकते हैं। मुझे निम्नलिखित कोड स्निपेट के साथ तकनीक का वर्णन करें:

 if (condition) { return a[i]; } 

सरलता के लिए, हम उस स्थिति को 0 या 1 मानते हैं। यदि सीपीयू a[i] सीमा से बाहर है, जब i सामान्य रूप से दुर्गम डेटा तक पहुंच प्राप्त कर रहा i , तो ऊपर वाला कोड कमजोर है। एक महत्वपूर्ण अवलोकन यह है कि इस स्थिति में, अटकलें पढ़ने की कोशिश करता a[i] जब स्थिति 0 । हमारा शमन इस कार्यक्रम को फिर से लिखता है ताकि यह मूल कार्यक्रम के समान ही व्यवहार करे, लेकिन किसी भी सट्टा लोड डेटा को लीक करने की अनुमति नहीं देता है।

हम एक सीपीयू रजिस्टर को आरक्षित करते हैं, जिसे हम "विष" कहते हैं, इस बात पर नज़र रखने के लिए कि क्या कोड गलत अर्थ में निष्पादित हो रहा है। जहर रजिस्टर सभी शाखाओं और उत्पन्न कोड के कॉल में समर्थित है, इसलिए किसी भी गलत तरीके से व्याख्या की गई शाखा के कारण जहर रजिस्टर 0 हो जाता है। फिर हम सभी मेमोरी एक्सेस को मापते हैं ताकि वे बिना जहर रजिस्टर के वर्तमान मूल्य के साथ सभी डाउनलोड के परिणाम को मुखौटा कर सकें। यह प्रोसेसर को शाखाओं की भविष्यवाणी (या गलत व्याख्या) से नहीं रोकता है, लेकिन यह गलत तरीके से व्याख्या की गई शाखाओं के कारण लोड किए गए मानों की जानकारी (संभवत: सीमा के बाहर) को नष्ट कर देता है। उपकरण कोड नीचे दिखाया गया है (संख्याओं की एक सरणी है)।

 let poison = 1; // … if (condition) { poison *= condition; return a[i] * poison; } 

अतिरिक्त कोड कार्यक्रम के सामान्य (वास्तुकला द्वारा परिभाषित) व्यवहार को प्रभावित नहीं करता है। यह केवल सट्टा निष्पादन के साथ सीपीयू पर काम करते समय माइक्रो-आर्किटेक्चरल स्थिति को प्रभावित करता है। यदि आप स्रोत कोड स्तर पर किसी प्रोग्राम को इंस्ट्रूमेंट करते हैं, तो आधुनिक कंपाइलरों में उन्नत अनुकूलन ऐसे इंस्ट्रूमेंटेशन को हटा सकते हैं। V8 में, हम कंपाइलर को संकलन के बहुत देर के चरण में डालकर मितली को दूर करने से रोकते हैं।

हम दुभाषिया लूपकोड और जावास्क्रिप्ट जावास्क्रिप्ट कॉल के अनुक्रम में अप्रत्यक्ष शाखाओं से लीक को रोकने के लिए भी इस विषाक्तता तकनीक का उपयोग करते हैं। दुभाषिया में, हम जहर को 0 सेट करते हैं यदि बायटेकोड हैंडलर (यानी, एक मशीन कोड अनुक्रम जो एक बाइटकोड की व्याख्या करता है) वर्तमान बायटेकोड से मेल नहीं खाता है। जावास्क्रिप्ट कॉल के लिए, हम लक्ष्य फ़ंक्शन को एक पैरामीटर (रजिस्टर में) के रूप में पास करते हैं और प्रत्येक फ़ंक्शन की शुरुआत में 0 पर जहर सेट करते हैं यदि आने वाले लक्ष्य फ़ंक्शन वर्तमान फ़ंक्शन से मेल नहीं खाते हैं। इस नरमी के साथ, हम ऑक्टेन बेंचमार्क में 20% से कम की मंदी देखते हैं।

WebAssembly के लिए शमन सरल है, क्योंकि मुख्य सुरक्षा जांच यह सुनिश्चित करना है कि मेमोरी एक्सेस सीमाओं के भीतर है। 32-बिट प्लेटफ़ॉर्म के लिए, सामान्य सीमा जांच के अलावा, हम सभी मेमोरी को दो की अगली शक्ति में भरते हैं और उपयोगकर्ता मेमोरी इंडेक्स के किसी भी ऊपरी बिट्स को बिना किसी नकाब के। 64-बिट प्लेटफार्मों को इस तरह के शमन की आवश्यकता नहीं है, क्योंकि कार्यान्वयन सीमा की जांच के लिए वर्चुअल मेमोरी सुरक्षा का उपयोग करता है। हमने संभावित रूप से असुरक्षित अप्रत्यक्ष शाखा का उपयोग करने के बजाय द्विआधारी खोज कोड में स्विच / केस स्टेटमेंट का संकलन किया, लेकिन यह कुछ वर्कलोड के लिए बहुत महंगा है। अप्रत्यक्ष कॉल रेटपोलिन द्वारा संरक्षित हैं।

सॉफ्टवेयर सुरक्षा - अविश्वसनीय

सौभाग्य से या दुर्भाग्य से, हमारे आक्रामक अनुसंधान रक्षात्मक की तुलना में बहुत तेजी से आगे बढ़े, और हमने स्पेक्टर हमलों के दौरान सभी संभावित लीक को प्रोग्रामेटिक रूप से कम करना असंभव पाया। इसके कई कारण हैं। सबसे पहले, स्पेक्टर का मुकाबला करने के इंजीनियरिंग प्रयास खतरे के स्तर के अनुपात में हैं। V8 में, हम कई अन्य सुरक्षा जोखिमों का सामना करते हैं, जो कि सामान्य बग (जो कि स्पेक्टर की तुलना में तेज़ और आसान है) के बाहर सीधे सीमाओं को पढ़ने से, बहुत खराब हैं, बाहरी सीमाओं के साथ लिखना (यह स्पेक्टर और बदतर के साथ असंभव है) और संभावित रिमोट कोड निष्पादन (स्पेक्टर के साथ असंभव और बहुत कुछ, बहुत बुरा)। दूसरे, तेजी से परिष्कृत शमन उपाय जो हमने विकसित किए और कार्यान्वित किए गए महत्वपूर्ण जटिलता को पूरा किया, जो एक तकनीकी दायित्व है और वास्तव में हमले की सतह और प्रदर्शन को बढ़ा सकते हैं। तीसरा, सूक्ष्मजैविकृत लीक के शमन का परीक्षण और रखरखाव भी एक हमले के लिए गैजेट्स को डिजाइन करने की तुलना में अधिक कठिन है, क्योंकि यह सुनिश्चित करना मुश्किल है कि मितली वे डिजाइन किए गए तरीके से काम करना जारी रखते हैं। कम से कम एक बार, महत्वपूर्ण शमन प्रभावी रूप से बाद में संकलक अनुकूलन द्वारा पूर्ववत किया गया था। चौथा, हमने पाया कि कुछ स्पेक्ट्रम विकल्पों को प्रभावी ढंग से कम करने के लिए, विशेष रूप से विकल्प 4, बस सॉफ्टवेयर में संभव नहीं है, यहां तक ​​कि हमारे ऐप्पल भागीदारों के वीर प्रयासों के बाद भी उनके जेआईटी कंपाइलर में समस्या से निपटने के लिए।

साइट अलगाव

हमारे शोध ने निष्कर्ष निकाला: सिद्धांत रूप में, अविश्वसनीय कोड स्पेक्टर और साइड चैनलों का उपयोग करके एक प्रक्रिया का पूरा पता स्थान पढ़ सकता है। सॉफ़्टवेयर शमन कई संभावित गैजेट की प्रभावशीलता को कम करते हैं, लेकिन प्रभावी या व्यापक नहीं हैं। एकमात्र प्रभावी उपाय प्रक्रिया पता स्थान के बाहर संवेदनशील डेटा को स्थानांतरित करना है। सौभाग्य से, सामान्य भेद्यता के कारण हमले की सतह को कम करने के लिए, क्रोम कई वर्षों से साइटों को अलग-अलग प्रक्रियाओं में बदलने की कोशिश कर रहा है। इन निवेशों ने भुगतान किया, और मई 2018 तक हमने तत्परता के स्तर पर लाया और अधिकतम प्लेटफार्मों पर साइटों के अलगाव का विस्तार किया। इस प्रकार, Chrome सुरक्षा मॉडल अब रेंडर प्रक्रिया के दौरान भाषा गोपनीयता को स्वीकार नहीं करता है।

स्पेक्टर ने एक लंबा सफर तय किया है और उद्योग और शिक्षाविदों में डेवलपर सहयोग की खूबियों पर जोर दिया है। अब तक, सफेद टोपी काले लोगों से आगे हैं। हम अभी भी एक भी वास्तविक हमले के बारे में नहीं जानते हैं, अवधारणा को साबित करने के लिए जिज्ञासु प्रयोगकर्ताओं और पेशेवर शोधकर्ताओं द्वारा गैजेट विकसित करने के अपवाद के साथ। इन कमजोरियों के नए रूप सामने आते रहते हैं और यह कुछ समय तक जारी रहेगा। हम इन खतरों की निगरानी करते हैं और उन्हें गंभीरता से लेते हैं।

कई प्रोग्रामर की तरह, हमने भी सोचा कि सुरक्षित भाषाएं अमूर्तता के लिए सही सीमा प्रदान करती हैं, अच्छी तरह से टाइप किए गए कार्यक्रमों को मनमाने ढंग से मेमोरी पढ़ने से रोकती हैं। यह दुख की बात है कि यह एक गलती है - यह गारंटी आज के उपकरणों के अनुरूप नहीं है। बेशक, हम अभी भी मानते हैं कि सुरक्षित भाषाओं में अधिक इंजीनियरिंग फायदे हैं, और भविष्य उनके साथ है, लेकिन ... आज के उपकरणों पर वे थोड़ा लीक करते हैं।

इच्छुक पाठक विषय में गहराई से तल्लीन कर सकते हैं और हमारे वैज्ञानिक लेख में अधिक विस्तृत जानकारी प्राप्त कर सकते हैं।