प्रत्येक सी प्रोग्रामर को सुरक्षा जोखिम / कमजोरियों के बारे में पता होना चाहिए? [बन्द है]

Question

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

जोखिम या भेद्यता (उदाहरण के लिए बफर ओवरफ्लो) क्या हैं जो प्रत्येक सी प्रोग्रामर को (आईई कमजोरियों से संबंधित है) इन समस्याओं के कारण क्या हो सकता है? इनसे कैसे बचें और इन कार्यक्रमों में क्या सामान्य गलतियाँ होती हैं?

Comments

इस सूची के बारे में क्या: owasp.org/index.php/Category:OWASP_Top_Ten_Project इससे अधिक क्या आवश्यक है?

— S.Lott

@ S.Lott: यह वेब विकास में सुरक्षा के मुद्दों के बारे में बहुत कुछ प्रतीत होता है। ऐसा लगता है कि सामान्य रूप से उस पर अधिक संसाधन हैं जो मैं वास्तव में पूछ रहा हूं, ऐसा लगता है।

— Anto

@ एंटो: सुरक्षा और आपके द्वारा पूछी जा रही सुरक्षा पर सभी संसाधनों के बीच अंतर करने के लिए कृपया प्रश्न को अपडेट करें ।

— एलटी

@ एस.लॉट: मुझे यकीन नहीं है कि आपका क्या मतलब है। मैं सुरक्षा सबसे C प्रोग्रामर से महत्व का है जो, यह है कि, बफर अतिप्रवाह और अन्य चीजों की तरह बातें जो सी में संभव हो रहे हैं के लिए पूछ

— Anto

@ एनेटो: "उस [वेब सिक्योरिटी?] पर सामान्य रूप से जो मैं पूछ रहा हूं, उससे कहीं अधिक संसाधन लगता है। ऐसा लगता है कि आप कुछ सुरक्षा के बारे में पूछ रहे हैं जो वेब सुरक्षा नहीं है। सच? यदि हां, तो कृपया यह बताने के लिए कि आप क्या देख रहे हैं , इस प्रश्न को अपडेट करें। असत्य? फिर आप वेब सुरक्षा के बारे में पूछ रहे हैं कि किस मामले में, आपके प्रश्न में उल्लिखित सूची का उल्लेख क्यों नहीं किया गया है?

— एस.लॉट

Answer 1

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

शोषण को रोकने के लिए कुछ कार्यान्वयन-स्तर की तकनीकें हैं, जैसे कि ढेर ब्लॉकों को खंगालना, लेकिन यह स्थानीय बफर में बफर ओवरफ्लो को रोक नहीं पाएगा, जो अक्सर दिलचस्प चीजें कर सकता है जैसे पता बदलने के लिए एक फ़ंक्शन वापस आ जाएगा।

सी में कोई अच्छा सामान्य समाधान नहीं है। कई लाइब्रेरी फ़ंक्शंस में ऐसे संस्करण हैं जो उस राशि को सीमित करेंगे जो वे लिखेंगे। यद्यपि यह गणना करना कि अनाड़ी हो सकता है। सॉफ्टवेयर है कि परीक्षण में ढेर बफर overflows का पता लगा सकते हैं, जब तक उचित परीक्षण चलाया जाता है, और स्टैक ओवरफ्लो अक्सर परीक्षण में एक दुर्घटना के रूप में दिखाई देगा। इसके अलावा, यह सावधानीपूर्वक कोडिंग और कोड समीक्षा की बात है।

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

printf()परिवार के साथ एक और जोखिम है । यदि आप कभी लिखते हैं char * str; ... printf(str);, तो आप अपने आप को समस्याओं के लिए सेट कर रहे हैं यदि strमुद्रित होने पर '%' होता है। %nप्रारूप के निर्देश की अनुमति देता है printf()स्मृति में लिखने के लिए। समाधान है printf("%s", str);या puts(str);। (इसके अलावा, C99 का उपयोग snprintf()करने के बजाय sprintf()।)

अहस्ताक्षरित पूर्णांक का उपयोग करना, विशेष रूप से लूप इंडेक्स के रूप में, समस्याएं पैदा कर सकता है। यदि आप एक छोटे से नकारात्मक मान को असाइन करते हैं, तो आपको एक बड़ा सकारात्मक मूल्य मिलता है। यह किसी चीज़ के केवल N उदाहरणों को संसाधित करने जैसी चीज़ों को सीमित कर सकता है, या जैसे सीमित कार्यों में strncpy()। सभी अहस्ताक्षरित पूर्णांक की जांच करें। आप बचना चाह सकते हैं unsigned short, क्योंकि उनमें से एक में एक बड़ा मूल्य एक में बड़े सकारात्मक मूल्य में बदल जाएगा int।

यह मत भूलो कि सी में एक चरित्र स्थिर, वास्तव में एक है int। जैसे कुछ लिखना char c; while((c = getchar()) != EOF) ...आसानी से विफल हो सकता है, क्योंकि EOFएक में प्रतिनिधित्व करने योग्य नहीं होगा char।

और भी बहुत सी विशिष्ट सी गलतियाँ हैं जिनके बारे में मैं सोच सकता हूँ, लेकिन ये सुरक्षा समस्याओं का कारण बन सकती हैं।

Comments

printf("%s", str)जब puts(str)एक ही काम करेंगे तब नग्न स्ट्रिंग के लिए उपयोग करने की कोई आवश्यकता नहीं है ।

— ब्लरफ्ल

@ ब्लरफ्ल लेकिन putsएक नई पंक्ति वर्ण जोड़ता है जबकि printfऐसा नहीं है।

— राइट

भी कर सकता है fputs(str, stdout), जो नहीं करता है।

— Blrfl

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

— सालेके

@DavidThornley: C11 & C ++ 14 मानक निकाले गए () मानक पुस्तकालय से इसकी खतरनाकता के कारण कार्य करता है।

— नाशक

Answer 2

सी-विशिष्ट जोखिमों में से कुछ में शामिल हैं: बफर ओवरफ्लो , स्ट्रिंग हमलों और पूर्णांक ओवरफ्लो का प्रारूपण ।

Comments

बफर ओवरफ्लो के बारे में सी-स्पेसिफिक कुछ भी नहीं है - पॉइंटर्स वाली किसी भी भाषा में यह हो सकता है। पूर्णांक ओवरफ्लो केवल किसी भी भाषा के बारे में लागू होता है, और आसानी से प्रबंधित कोड में भी हो सकता है।

— स्टीव

@ सच में, यह वास्तव में संकेत नहीं है कि समस्या का कारण है, लेकिन कैसे भाषा सरणी सीमा लागू नहीं करता है।

— डग टी।

@ सवाल यह है कि सामान के बारे में नहीं पूछ रहा था जो केवल सी की चिंता करता है, लेकिन कुछ ऐसा जो सी प्रोग्रामर को पता होना चाहिए।

— अटैकिंगहोबो

@ समय: सी असामान्य रूप से बफर ओवरफ्लो के लिए अतिसंवेदनशील है, आंशिक रूप से रेंज-चेकिंग के लिए समर्थन की कमी के कारण, और लाइब्रेरी फ़ंक्शंस की संख्या जो ख़ुशी से आपके लिए बफ़र्स को ओवरफ्लो करेगी।

— डेविड थॉर्नले

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

— स्टीव

Answer 3

यहां जोखिम को याद करना आसान है जिससे समस्याएं हो सकती हैं जिन्हें ठीक करने में घंटों लगेंगे।

निम्नलिखित कोड पर विचार करें, जो बिना किसी समस्या के संकलन करेगा।

if(lpstr_current_state = CONST_EMERGENCY_STATE_HOLY_CRAP)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

जब आप देखें कि lpstr_current_stateक्या CONST_EMERGENCY_STATE_HOLY_CRAPआप वास्तव में असाइन कर रहे हैं। हमेशा बाईं ओर स्थिर चर रखना बेहतर होता है। जब आप स्थिरांक को बाईं ओर रखते हैं, तो कंपाइलर विफल हो जाएगा क्योंकि आप किसी वैरिएबल को मान नहीं दे सकते हैं।

if(CONST_EMERGENCY_STATE_HOLY_CRAP = lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

फिर आप आसानी से अपने आप से कह सकते हैं, "पवित्र बकवास, जो बुरा हो सकता था", जबकि पढ़ने के लिए कोड को ठीक करना ...

if(CONST_EMERGENCY_STATE_HOLY_CRAP == lpstr_current_state)
{
    do_warn_joint_chiefs_of_staff_of_nuclear_attack();
}

Comments

एक कंपाइलर को कुछ अन्य समस्याओं के विपरीत, चेतावनी के रूप में पकड़ना और झंडा लगाना आसान है। दुर्भाग्य से, सभी संकलक ऐसा करना आसान नहीं बनाते हैं।

— डेविड थॉर्नले

सी के अलावा अन्य भाषाओं में भी हो सकता है, कोई भी भाषा जो उपयोग करती है =और ==।

— FrustratedWithFormsDesigner

यह भी वास्तव में सुरक्षा भेद्यता नहीं है, यह एक बग है।

— क्रिस पिटमैन

इन्हें योडा स्थिति कहा जाता है।

@ क्रिस्‍टोफर होच: यदि हम किसी भी संभावित सी बग को जोखिम कहते हैं, और इस पर विचार करें, तो हमें एक बहुत बड़े मंच की जरूरत होगी।

— डेविड थॉर्नले

Answer 4

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

इसलिए जब आप सोचते हैं कि "उनके सही दिमाग में कोई भी नहीं होगा ...", तो आपको तुरंत सोचने की ज़रूरत है "सिवाय इसके कि कोई व्यक्ति जो अन्य लोगों के कंप्यूटर में हैक करना चाहता है, वह ठीक यही करेगा"।

सबसे बड़ा परिणाम यह है कि जब भी आप बाहर की घटनाओं पर प्रतिक्रिया करते हैं (उदाहरण के लिए, बाहर से वितरित डेटा संसाधित करके), तो आपको यह मान लेना चाहिए कि यह डेटा आपके सबसे बड़े दुश्मन के नियंत्रण में था।

Comments

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

— cmaster - मोनिका