Google ने ब्राउज़र में जावास्क्रिप्ट निष्पादन के माध्यम से स्पेक्टर कमजोरियों के शोषण का प्रदर्शन किया

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

प्रस्तावित प्रोटोटाइप को Linux और Chrome 7 वाले वातावरण में Intel Core i6500-88U प्रोसेसर वाले सिस्टम पर हमला करने के लिए डिज़ाइन किया गया है। अन्य वातावरणों के लिए शोषण का उपयोग करने के लिए, संशोधनों की आवश्यकता होती है। शोषण विधि इंटेल प्रोसेसर के लिए विशिष्ट नहीं है - उचित अनुकूलन के बाद, शोषण की पुष्टि एआरएम आर्किटेक्चर पर आधारित ऐप्पल एम 1 सहित अन्य निर्माताओं के सीपीयू वाले सिस्टम पर काम करने के लिए की गई थी। मामूली समायोजन के बाद, शोषण अन्य ऑपरेटिंग सिस्टम और क्रोमियम इंजन पर आधारित अन्य ब्राउज़रों में भी काम करने योग्य है।

मानक क्रोम 88 और इंटेल स्काईलेक प्रोसेसर पर आधारित वातावरण में, वर्तमान क्रोम टैब (रेंडरर प्रक्रिया) में वेब सामग्री को संसाधित करने के लिए जिम्मेदार प्रक्रिया से 1 किलोबाइट प्रति सेकंड की गति से डेटा लीक करना संभव था। इसके अतिरिक्त, वैकल्पिक प्रोटोटाइप विकसित किए गए हैं, उदाहरण के लिए, एक शोषण जो स्थिरता को कम करने की कीमत पर, 8 माइक्रोसेकंड (5 मिलीसेकंड) की सटीकता के साथ Performance.now() टाइमर का उपयोग करते समय रिसाव दर को 0.005kB/s तक बढ़ाने की अनुमति देता है। ). एक संस्करण भी तैयार किया गया था जो एक मिलीसेकंड की टाइमर सटीकता के साथ काम करता था, जिसका उपयोग लगभग 60 बाइट्स प्रति सेकंड की गति से किसी अन्य प्रक्रिया की मेमोरी तक पहुंच को व्यवस्थित करने के लिए किया जा सकता था।

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

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

प्रस्तावित शोषण तकनीक, Performance.now() API के माध्यम से उपलब्ध उच्च-सटीक टाइमर के बिना और SharedArrayBuffer प्रकार के समर्थन के बिना ऐसा करना संभव बनाती है, जो साझा मेमोरी में सरणियाँ बनाने की अनुमति देता है। शोषण में स्पेक्टर गैजेट शामिल है, जो कोड के नियंत्रित सट्टा निष्पादन का कारण बनता है, और एक साइड-चैनल लीक विश्लेषक, जो सट्टा निष्पादन के दौरान प्राप्त कैश्ड डेटा का पता लगाता है।

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

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

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

स्रोत: opennet.ru