श्रृंखला के पिछले लेखों में, हमने रस्ट में मेमोरी सुरक्षा और थ्रेड सुरक्षा पर चर्चा की। इस अंतिम लेख में, हम क्वांटम सीएसएस परियोजना का उपयोग करते हुए एक वास्तविक जंग आवेदन के निहितार्थ को देखेंगे।

CSS इंजन पृष्ठ पर CSS नियम लागू करता है। यह एक अवरोही प्रक्रिया है जो DOM ट्री को उतारेगी, अभिभावक CSS की गणना करने के बाद, बाल शैलियों की गणना स्वतंत्र रूप से की जा सकती है: समानांतर कंप्यूटिंग के लिए आदर्श। 2017 तक, मोज़िला ने C ++ का उपयोग करके स्टाइल सिस्टम को समानांतर बनाने के लिए दो प्रयास किए। दोनों असफल रहे।

उत्पादकता बढ़ाने के लिए क्वांटम सीएसएस विकास शुरू हो गया है। सुरक्षा में सुधार सिर्फ एक अच्छा साइड इफेक्ट है।


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

सभी समय के लिए फ़ायरफ़ॉक्स के सीएसएस घटक में 69 सुरक्षा त्रुटियों का पता चला है। यदि हमारे पास एक टाइम मशीन थी और हम इसे शुरू से ही जंग लिख सकते हैं, तो 51 (73.9%) त्रुटियां असंभव हो जाएंगी। हालाँकि Rust लिखने में अच्छे कोड को आसान बनाता है, यह पूर्ण सुरक्षा भी प्रदान करता है।

रतुआ

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

• अविश्वसनीय आने वाले डेटा की सुरक्षित प्रसंस्करण;
  
• प्रदर्शन में सुधार करने के लिए संगामिति;
  
• मौजूदा कोड बेस में व्यक्तिगत घटकों का एकीकरण।

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

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

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

क्वांटम सीएसएस सुरक्षा त्रुटियां

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

श्रेणी के अनुसार सुरक्षा त्रुटियां

• मेमोरी: 32
  
• सीमाएँ: १२
  
• कार्यान्वयन: 12
  
• अशक्त::
  
• स्टैक ओवरफ्लो: 3
  
• पूर्णांक अतिप्रवाह: २
  
• अन्य: 1

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

मेमोरी कमजोरियों को अक्सर गंभीर सुरक्षा मुद्दों के रूप में वर्गीकृत किया जाता है। 34 महत्वपूर्ण / गंभीर मुद्दों में से 32 मेमोरी से संबंधित थे।

सुरक्षा कीड़े की गंभीर वितरण

• कुल: 70
  
• सुरक्षा त्रुटियां: 43
  
• गंभीर / गंभीर: 34
  
• निश्चित जंग: 32

रस्ट और सी ++ की तुलना

बग 955913 - GetCustomPropertyNameAt फ़ंक्शन में ढेर बफर अतिप्रवाह। कोड ने इंडेक्सिंग के लिए गलत चर का उपयोग किया, जिसके कारण सरणी के अंत के बाद मेमोरी की व्याख्या हुई। खराब पॉइंटर तक पहुँचने या किसी दूसरे कंपोनेंट को पास करने वाले स्ट्रिंग में मेमोरी कॉपी करने के कारण यह क्रैश हो सकता है।

सभी सीएसएस गुणों (कस्टम, यानी कस्टम) का mOrder सरणी में संग्रहीत है। प्रत्येक तत्व या तो एक सीएसएस संपत्ति मूल्य द्वारा दर्शाया गया है, या, कस्टम गुणों के मामले में, एक मान जो eCSSProperty_COUNT (गैर-कस्टम सीएसएस गुणों की कुल संख्या) से शुरू होता है। कस्टम गुणों का नाम पाने के लिए, आपको पहले mOrder से मान प्राप्त करने की आवश्यकता है, और फिर mVariableOrder सरणी के संबंधित सूचकांक में नाम का उपयोग करें, जो क्रम में कस्टम गुणों के नामों को संग्रहीत करता है।

कमजोर C ++ कोड:

  void GetCustomPropertyNameAt(uint32_t aIndex, nsAString& aResult) const { MOZ_ASSERT(mOrder[aIndex] >= eCSSProperty_COUNT); aResult.Truncate(); aResult.AppendLiteral("var-"); aResult.Append(mVariableOrder[aIndex]); 

समस्या 6 लाइन पर होती है जब aIndex का उपयोग mVariableOrder सरणी के तत्व तक पहुंचने के लिए किया mVariableOrder । तथ्य यह है कि aIndex का उपयोग mOrder ऐरे के साथ किया जाना चाहिए, न कि mVariableOrder । aIndex में mOrder द्वारा aIndex गई कस्टम संपत्ति के लिए संबंधित तत्व वास्तव में mOrder[aIndex] - eCSSProperty_COUNT ।

सही C ++ कोड:

  void Get CustomPropertyNameAt(uint32_t aIndex, nsAString& aResult) const { MOZ_ASSERT(mOrder[aIndex] >= eCSSProperty_COUNT); uint32_t variableIndex = mOrder[aIndex] - eCSSProperty_COUNT; aResult.Truncate(); aResult.AppendLiteral("var-"); aResult.Append(mVariableOrder[variableIndex]); } 

रस्ट कोड

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

  fn GetCustomPropertyNameAt(&self, aIndex: usize) -> String { assert!(self.mOrder[aIndex] >= self.eCSSProperty_COUNT); let mut result = "var-".to_string(); result += &self.mVariableOrder[aIndex]; result } 

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

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

टीएल, डॉ

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

कंपाइलर सभी प्रोग्रामर त्रुटियों को पकड़ नहीं सकते हैं। फिर भी, रस्ट हमारी मेमोरी सुरक्षा बोझ को हटा देता है, जिससे हमें कोड की तार्किक शुद्धता पर ध्यान केंद्रित करने की अनुमति मिलती है।