सी भाषा बहुत शक्तिशाली है और इसका बहुत उपयोग किया जाता है जहां - विशेष रूप से लिनक्स कर्नेल में - लेकिन यह बहुत खतरनाक भी है। एक लिनक्स कर्नेल डेवलपर ने बताया कि सी सुरक्षा कमजोरियों से कैसे निपटें।आप सी में लगभग कोई भी काम कर सकते हैं, लेकिन इसका मतलब यह नहीं है कि इसे करने की आवश्यकता है। सी कोड बहुत तेज़ है, लेकिन बिना सीट बेल्ट के चलाया जाता है। यहां तक कि अगर आप एक विशेषज्ञ हैं, तो
अधिकांश लिनक्स कर्नेल डेवलपर्स की तरह , हत्यारा त्रुटियां अभी भी संभव हैं।
पॉइंटर एलियासेस जैसे नुकसान के अलावा, सी में मौलिक गलतियां हैं जो अपने पीड़ितों की प्रतीक्षा करती हैं। ये वे कमजोरियां हैं जो वैंकूवर में
लिनक्स सुरक्षा सम्मेलन में संबोधित किए गए
केस कुक , Google लिनक्स कर्नेल सुरक्षा इंजीनियर हैं।
“सी एक तरह का असेंबलर है। यह लगभग मशीन कोड है, "कुक ने कई सौ सहयोगियों के दर्शकों का जिक्र किया, जो सी पर अनुप्रयोगों की गति को समझते हैं और उनकी सराहना करते हैं। लेकिन बुरी खबर यह है कि" सी कुछ खतरनाक सामान, अस्पष्ट व्यवहार और अन्य कमजोरियों के साथ आता है, जिसके कारण
सुरक्षा छेद और कमजोर बुनियादी ढांचा। ”
यदि आप अपनी परियोजनाओं में सी का उपयोग करते हैं, तो आपको सुरक्षा समस्याओं पर ध्यान देना चाहिए।
लिनक्स कर्नेल सुरक्षा
समय के साथ, कुक और सहयोगियों ने देशी सी के साथ कई समस्याओं की खोज की। उन्हें संबोधित करने के लिए,
कर्नेल सेल्फ प्रोटेक्शन प्रोजेक्ट लॉन्च किया गया था। वह धीरे-धीरे और लगातार लिनक्स कर्नेल को हमलों से बचाने के लिए काम करता है, समस्याग्रस्त कोड को वहां से हटा देता है।
कुक कहते हैं, यह जटिल है, क्योंकि "कर्नेल को मेमोरी मैनेजमेंट, इंटरप्ट हैंडलिंग, शेड्यूलिंग और इतने पर किसी विशेष आर्किटेक्चर के लिए चीजों को बहुत विशिष्ट करने की आवश्यकता होती है।" बड़ी मात्रा में कोड विशिष्ट कार्यों को संदर्भित करता है जिन्हें सावधानीपूर्वक जांचने की आवश्यकता होती है। उदाहरण के लिए, "C में टेबल टेबल सेट करने या 64-बिट मोड पर स्विच करने के लिए API नहीं है," उन्होंने कहा।
इस तरह के भार के साथ और सी में कमजोर मानक पुस्तकालयों के साथ, बहुत अधिक अस्पष्ट व्यवहार है। कुक ने हवाला दिया - और सहमत हैं - रफ लेविन
के ब्लॉग लेख के
साथ ,
"अपरिभाषित व्यवहार के साथ, सब कुछ असंभव है ।
"कुक ने विशिष्ट उदाहरण दिए: "असिंचित" चर की सामग्री क्या है? यह सब पहले मेरी याद में था! शून्य सूचक में कोई प्रकार नहीं हैं, लेकिन टाइप किए गए कार्यों को उनके माध्यम से कहा जा सकता है? बेशक! विधानसभा सभी समान है: आप किसी भी पते से संपर्क कर सकते हैं!
memcpy() पास तर्क 'अधिकतम गंतव्य लंबाई' क्यों नहीं है? यह मायने नहीं रखता, जैसा आप कहते हैं वैसा ही करते हैं; सभी मेमोरी क्षेत्र समान हैं! "
चेतावनियों को अनदेखा करना ... लेकिन हमेशा नहीं
इन सुविधाओं में से कुछ को संभालना अपेक्षाकृत आसान है। कुक ने टिप्पणी की: "लिनुस [टोरवाल्ड्स] को हमेशा स्थानीय चर को शुरू करने का विचार पसंद है। तो बस करो। ”
लेकिन आरक्षण के साथ। यदि आप स्विच में एक स्थानीय वैरिएबल को इनिशियलाइज़ करते हैं, तो आपको एक चेतावनी मिलेगी: "कंपाइलर कोड को प्रोसेस करने के तरीके के कारण" स्टेटमेंट कभी भी निष्पादित नहीं किया जाएगा
[-Wswitch-unreachable] । इस चेतावनी को नजरअंदाज किया जा सकता है।
लेकिन सभी चेतावनियों को नजरअंदाज नहीं किया जा सकता है। "वैरिएबल लेंथ एरे हमेशा खराब होते हैं," कुक ने कहा। अन्य मुद्दों में स्टैक थकावट, लाइन अतिप्रवाह और पृष्ठ सुरक्षा उल्लंघन शामिल हैं। इसके अलावा, कुक ने
वीएलए की सुस्ती पर ध्यान आकर्षित किया। कर्नेल से सभी वीएलए को हटाकर प्रदर्शन में 13% की वृद्धि हुई। गति और सुरक्षा दोनों में सुधार एक दोहरा लाभ है।
हालाँकि VLAs को कर्नेल से लगभग हटा दिया गया था, फिर भी वे कुछ कोड में बने रहे। सौभाग्य से, वीएलए को
-Wvla संकलक
-Wvla का उपयोग करना आसान है।
सी। के शब्दार्थ में एक और समस्या छिपी हुई है। यदि स्विच में ब्रेक गायब है, तो प्रोग्रामर का क्या मतलब है? ब्रेकिंग ब्रेक से कई स्थितियों से कोड निष्पादन हो सकता है; यह एक जाना माना मुद्दा है।
यदि आप मौजूदा कोड में ब्रेक / स्विच स्टेटमेंट की तलाश कर रहे हैं, तो आप नए स्विच स्टेटमेंट को जोड़ने के लिए
-Wimplicit-fallthrough का उपयोग कर सकते हैं। यह वास्तव में एक टिप्पणी है, लेकिन आधुनिक संकलक इसे पार्स करते हैं। आप
एक "गिरावट" टिप्पणी के साथ स्पष्ट रूप से विराम की अनुपस्थिति को भी
चिह्नित कर सकते हैं।
स्लैब मेमोरी आवंटन के लिए सीमाओं की जाँच करते समय कुक ने एक प्रदर्शन हिट पाया। उदाहरण के लिए,
strcpy()-family जाँच
strcpy()-family 2% से प्रदर्शन को कम करता है।
strncpy() जैसे
strncpy() अपनी समस्याएं हैं। स्ट्रैन्की बाहर निकलता है हमेशा एक अशक्त चरित्र के साथ समाप्त नहीं होता है। कुक ने दर्शकों को दुखी किया: "मुझे सबसे अच्छा एपीआई कहां मिल सकता है?"
क्यू एंड ए सत्र के दौरान, एक लिनक्स डेवलपर ने पूछा, "क्या मैं पुराने, खराब एपीआई से छुटकारा पा सकता हूं?" कुक ने कहा कि लिनक्स ने कुछ समय के लिए विरासत एपीआई की अवधारणा का समर्थन किया। फिर भी, टॉर्वाल्ड्स ने इस विचार को खारिज कर दिया, यह तर्क देते हुए कि यदि कोई एपीआई तारीख से बाहर है, तो इसे पूरी तरह से फेंक दिया जाना चाहिए। हालांकि, हमेशा के लिए एपीआई को गिराना "राजनीतिक रूप से खतरनाक है," कुक ने कहा। इसलिए जब तक हम डटे रहे।
समस्या का दीर्घकालिक समाधान? सुरक्षा मुद्दों को समझने वाले अधिक डेवलपर्स
कुक एक लंबी और कठिन यात्रा की उम्मीद करता है। एक बार लिनक्स सी बोली बनाने का विचार आकर्षक लग रहा था, लेकिन यह नहीं होगा। खतरनाक कोड के साथ वास्तविक समस्या यह है कि "लोग कोड की सफाई का काम नहीं करना चाहते हैं - न केवल बुरा कोड, बल्कि स्वयं सी," उन्होंने कहा। सभी ओपन सोर्स प्रोजेक्ट्स की तरह, "हमें और अधिक समर्पित डेवलपर्स, समीक्षकों, परीक्षकों, और बैकपोर्ट विशेषज्ञों की आवश्यकता है।"
खतरनाक सी: सबक
- सी एक परिपक्व और शक्तिशाली भाषा है, लेकिन यह तकनीकी कठिनाइयों और सुरक्षा समस्याओं को पैदा करती है।
- लिनक्स डेवलपर्स सी (अपनी शक्ति को खोए बिना) पर विशेष ध्यान देते हैं, क्योंकि अधिकांश ऑपरेटिंग सिस्टम इस पर लिखा गया है।
- लिनक्स लिनक्स कर्नेल सुरक्षा इंजीनियर ने विशिष्ट भाषा कमजोरियों की पहचान की और बताया कि उन्हें कैसे बचा जाए।