क्रोमियम में 70% सुरक्षा समस्याएँ मेमोरी त्रुटियों के कारण होती हैं

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

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

कोडबेस की सुरक्षा बनाए रखने के लिए, Google "दो का नियम“, जिसके अनुसार किसी भी जोड़े गए कोड को तीन में से दो से अधिक शर्तों को पूरा नहीं करना चाहिए: अमान्य इनपुट डेटा के साथ काम करना, असुरक्षित प्रोग्रामिंग भाषा (सी/सी++) का उपयोग करना और उन्नत विशेषाधिकारों के साथ चलना। इस नियम का तात्पर्य है कि बाहरी डेटा को संसाधित करने के लिए कोड को या तो न्यूनतम विशेषाधिकारों (पृथक) तक कम किया जाना चाहिए या एक सुरक्षित प्रोग्रामिंग भाषा में लिखा जाना चाहिए।

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

उम्मीद है कि काम दो क्षेत्रों पर केंद्रित होगा:

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

स्मृति-सुरक्षित पुस्तकालयों का उपयोग करना सबसे सरल, लेकिन कम कुशल तरीका भी है। रस्ट में कोड को दोबारा लिखना सबसे प्रभावी, लेकिन बहुत महंगा तरीका भी माना जाता है।

स्रोत: opennet.ru