मैं स्पेक्टर के बारे में नहीं लिखना चाहता, लेकिन मुझे यह करना होगा: पिछले हफ्ते यह अब तक की सबसे महत्वपूर्ण खबर है। शिक्षाविदों द्वारा मूल की तरह स्पेक्टर की नई कमजोरियों को दिखाया गया है। मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी के एक शोधकर्ता व्लादिमीर किर्यांस्की और स्वतंत्र विशेषज्ञ कार्ल वॉल्डसपर्गर ने स्पेक्टर को दो नए संशोधन दिखाए, जिन्हें स्पेक्टर 1.1 और स्पेक्टर 1.2 (
नवीनता , मूल
वैज्ञानिक कार्य ) कहा जाता है, बिना किसी लोगो या लोगो के।
दोनों मामलों में मूल स्पेक्टर भेद्यता से महत्वपूर्ण अंतर एक सट्टा रिकॉर्डिंग तंत्र का उपयोग है। स्पेक्टर 1.1 के मामले में, एक हमला सैद्धांतिक रूप से आपको एक (भी सट्टा) बफर अतिप्रवाह का कारण बनता है और स्मृति के "निषिद्ध" अनुभाग को पढ़ने की अनुमति देता है। स्पेक्टर 1.2 रीड-ओनली सूचना को अधिलेखित करने की क्षमता प्रदान करता है और सैद्धांतिक रूप से हार्डवेयर सुरक्षा प्रणालियों को बायपास एस्केप अटैक को अनुमति देता है। भेद्यता की खोज के लिए, शोधकर्ताओं ने इंटेल के बग बगाउंट कार्यक्रम के हिस्से के रूप में एक लाख डॉलर प्राप्त किए, और आज यह सबसे बड़े भुगतानों में से एक है। कमजोरियां इंटेल, एआरएम प्रोसेसर और, शायद, एएमडी प्रोसेसर से प्रभावित होती हैं।
लेखकों के अनुसार, अध्ययन के प्रमुख निष्कर्षों में से एक "सट्टा बफर अतिप्रवाह" की नई अवधारणा है। एक अतिप्रवाह एक लेखन ऑपरेशन का कारण बनता है - सही समय पर और सही जगह पर प्रदर्शन किया, यह अनिवार्य रूप से गलत के रूप में खारिज कर दिया जाएगा, लेकिन इससे पहले भी यह एक मेमोरी क्षेत्र को पढ़ने की संभावना को खोलता है जिस पर हमला करने की प्रक्रिया तक पहुंच नहीं होनी चाहिए।
विचार का एक प्रमुख उदाहरण: सीमा जाँच मूल स्पेक्टर की तरह एक रीड ऑपरेशन का उपयोग नहीं कर रही है, लेकिन एक लिखित ऑपरेशन के साथ।उन परिस्थितियों की सूची, जिनके तहत व्यवहार में नई कमजोरियों को लागू किया जा सकता है, हमले तंत्र के विवरण की तुलना में लगभग अधिक स्थान लेती हैं। यह इस वर्ग की हार्डवेयर कमजोरियों की जटिलता है: हमले के सफल होने के लिए बहुत अधिक संयोग होना चाहिए। लेकिन जब कोई हमला होता है, तो सबसे खराब स्थिति में, यह आपको बहुमूल्य जानकारी चुराने की अनुमति देता है, अक्सर पोस्ट फैक्टम समझ की संभावना के बिना, बिल्कुल ऐसा ही हुआ। सबसे महत्वपूर्ण: स्पेक्ट्रर 1.0 हमले संभव नहीं होने पर भी 1.x स्थितियां बनाई जा सकती हैं।
शोधकर्ताओं का तर्क है कि कोड विश्लेषण या संकलन उपकरण के माध्यम से स्पेक्टर 1.1 जैसी कमजोरियों का पता लगाने का कोई तरीका नहीं है। इसके अलावा, यह भेद्यता लोहे के स्तर पर बंद हो सकती है। यह भी ध्यान दिया जाता है कि एक सफल स्पेक्टर हमले के जोखिम को कम करने की जिम्मेदारी अक्सर सॉफ्टवेयर डेवलपर्स की होती है। यह देखते हुए कि बफर ओवरफ्लो के साथ एक हमले के पहले सार्वजनिक प्रदर्शन के बाद से 30 साल बीत चुके हैं, सॉफ्टवेयर में कमजोरियां बहुत कम हो गई हैं, लेखक प्रासंगिकता के "दशक" के सट्टा कोड निष्पादन के तंत्र पर हमलों की भविष्यवाणी करते हैं।
पूर्वगामी के बावजूद, लेखकों का मानना है कि सट्टा निष्पादन तंत्र के खिलाफ सुरक्षा के लाभों के साथ सुरक्षित सॉफ़्टवेयर और हार्डवेयर का संयोजन सैद्धांतिक रूप से संभव है। यह व्यवहार में इसे लागू करने के लिए बनी हुई है, कि हार्डवेयर को प्रभावित करने वाली कमजोरियों के एक वर्ग के मामले में, यह या तो साल या दशकों तक ले सकता है। मुझे आश्चर्य है कि अगर स्पेक्टर / मेल्टडाउन और उसके डेरिवेटिव की कहानी विकासशील सॉफ्टवेयर और हार्डवेयर के अभ्यास में कुछ गंभीर बदलाव की दिशा में एक कदम नहीं बनेगी?
डिस्क्लेमर: इस डाइजेस्ट में व्यक्त की गई राय हमेशा कास्परस्की लैब की आधिकारिक स्थिति से मेल नहीं खा सकती है। प्रिय संपादकों आमतौर पर स्वस्थ संदेह के साथ किसी भी राय का इलाज करने की सलाह देते हैं।