😤 🤖 📀 हम पैर में गोली मारते हैं, इनपुट डेटा को संसाधित करते हैं 🧓🏿 👕 👉🏾

आज के लेख में लिंक सामान्य से अलग है। यह एक परियोजना नहीं है जिसके लिए स्रोत कोड का विश्लेषण किया गया था, लेकिन कई अलग-अलग परियोजनाओं में एक ही नैदानिक नियम की प्रतिक्रियाओं की एक श्रृंखला है। यहाँ क्या रुचि है? तथ्य यह है कि कुछ माना कोड के टुकड़े में त्रुटियां हैं जो आवेदन के साथ काम करते समय प्रतिलिपि प्रस्तुत करने योग्य होती हैं, जबकि अन्य में पूरी तरह से कमजोरियां (सीवीई) होती हैं। इसके अलावा, लेख के अंत में हम सुरक्षा दोषों के विषय पर थोड़ी चर्चा करेंगे।

संक्षिप्त प्रस्तावना

लेख में आज जिन सभी त्रुटियों पर विचार किया जाएगा उनमें एक समान पैटर्न है:

कार्यक्रम स्टडिन स्ट्रीम से डेटा प्राप्त करता है;
डेटा पढ़ने की सफलता के लिए एक चेक बनाया गया है;
यदि डेटा सफलतापूर्वक पढ़ा गया था, तो कैरक्टर को लाइन से हटा दिया जाता है।

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

नीचे दी गई सभी समस्याओं की खोज PVS-Studio स्थैतिक विश्लेषक ने की थी , जो न केवल C, C ++, बल्कि C #, Java के लिए कोड में त्रुटियों की खोज करता है।

बेशक, एक स्थैतिक विश्लेषक के साथ एक समस्या ढूंढना अच्छा है, लेकिन खोज करना और पुन: प्रस्तुत करना पूरी तरह से खुशी का एक अलग स्तर है। :)

Freeswitch

पहला संदिग्ध कोड टुकड़ा fs_cli.exe मॉड्यूल के कोड में पाया गया, जो FreeSWITCH वितरण किट का हिस्सा है:

static const char *basic_gets(int *cnt) { .... int c = getchar(); if (c < 0) { if (fgets(command_buf, sizeof(command_buf) - 1, stdin) != command_buf) { break; } command_buf[strlen(command_buf)-1] = '\0'; /* remove endline */ break; } .... }

PVS-Studio चेतावनी : V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग इंडेक्स में किया जाता है: 'strlen (कमांड_ब्यूफ)'।

विश्लेषक एक संदिग्ध कॉल को इंडेक्स द्वारा कमांड_ब्यू सरणी पर चेतावनी देता है। यह इस कारण के लिए संदिग्ध माना जाता है कि असत्यापित बाहरी डेटा को एक सूचकांक के रूप में उपयोग किया जाता है। बाहरी - क्योंकि वे स्टडिन स्ट्रीम से फिट्स फ़ंक्शन के माध्यम से प्राप्त किए जाते हैं। असत्यापित - चूंकि उपयोग से पहले कोई सत्यापन नहीं किया गया था। अभिव्यक्ति (कमांड_ब्यूफ, ....)! = Command_buf की गणना नहीं होती है, क्योंकि इस तरह हम केवल डेटा प्राप्त करने के तथ्य की जांच करते हैं, लेकिन इसकी सामग्री की नहीं।

इस कोड के साथ समस्या यह है कि, कुछ शर्तों के तहत, सरणी के बाहर '\ 0' लिखा जाएगा, जिससे अपरिभाषित व्यवहार होगा। ऐसा करने के लिए, बस शून्य लंबाई (सी भाषा के दृष्टिकोण से शून्य लंबाई की एक स्ट्रिंग) दर्ज करें, अर्थात, जिसमें से पहला वर्ण '\ 0' होगा।

चलिए अनुमान लगाते हैं कि यदि आप इनपुट में एक शून्य-लंबाई स्ट्रिंग पास करते हैं तो क्या होता है:

fgets (कमांड_बुफ, ....) -> कमांड_बुफ ;
fgets (....)! = command_buf -> false ( फिर यदि स्टेटमेंट की शाखा को नजरअंदाज किया जाता है);
strlen (command_buf) -> 0 ;
command_buf [strlen (कमांड_buf) - 1] -> command_buf [-1] ।

ऊप्स!

यहां दिलचस्प बात यह है कि यह विश्लेषक चेतावनी "अपने हाथों से महसूस की जा सकती है।" समस्या को दोहराने के लिए, आपको आवश्यकता है:

इस समारोह में कार्यक्रम लाओ;
ठीक-ठीक इनपुट करें ताकि गेटचेयर () कॉल एक नकारात्मक मान लौटाए;
फ़िज़ के लिए पास शुरू में एक टर्मिनल शून्य के साथ एक पंक्ति का कार्य करता है, जिसे इसे सफलतापूर्वक पढ़ना चाहिए।

स्रोत में थोड़ा सा रम, मैंने समस्या को पुन: पेश करने के लिए एक विशिष्ट अनुक्रम बनाया:

बैच मोड में fs_cli.exe चलाएं ( fs_cli.exe -b )। मैं ध्यान देता हूं कि आगे के चरण करने के लिए, सर्वर के लिए fs_cli.exe कनेक्शन सफल होना चाहिए। ऐसा करने के लिए, यह पर्याप्त है, उदाहरण के लिए, FreeSwitchConsole.exe को स्थानीय रूप से व्यवस्थापक के रूप में चलाने के लिए।
हम इनपुट बाहर ले जाते हैं ताकि गेटचेयर () कॉल एक नकारात्मक मान लौटाए।
शुरुआत में एक टर्मिनल शून्य के साथ एक पंक्ति दर्ज करें (उदाहरण के लिए, '\ 0 ओह्स')।
....
लाभ!

निम्नलिखित समस्या का एक वीडियो प्लेबैक है:

NcFTP

एनसीएफटीपी परियोजना में एक समान समस्या की खोज की गई थी, लेकिन यह पहले से ही दो स्थानों पर मिली थी। चूंकि कोड समान दिखता है, केवल एक समस्याग्रस्त स्थान पर विचार करें:

 static int NcFTPConfirmResumeDownloadProc(....) { .... if (fgets(newname, sizeof(newname) - 1, stdin) == NULL) newname[0] = '\0'; newname[strlen(newname) - 1] = '\0'; .... }

PVS-Studio चेतावनी : V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग सूचकांक में किया जाता है: 'strlen (newname)'।

यहां, FreeSWITCH के उदाहरण के विपरीत, कोड को समस्याओं के बदतर और अधिक संभावित रूप से लिखा गया है। उदाहरण के लिए, '\ 0' लिखना इस बात की परवाह किए बिना होता है कि क्या रीड फॉक्स का उपयोग करने में सफल था या नहीं। यही है, निष्पादन के सामान्य तर्क को कैसे तोड़ना है, इसके लिए और भी अधिक संभावनाएं हैं। चलो एक सिद्ध तरीके से चलते हैं - शून्य लंबाई की लाइनों के माध्यम से।

पुनरुत्पादित समस्या FreeSWITCH की तुलना में थोड़ी अधिक जटिल है। चरणों का क्रम नीचे वर्णित है:

सर्वर से शुरू और कनेक्ट करना जिससे आप फ़ाइल डाउनलोड कर सकते हैं। उदाहरण के लिए, मैंने speedtest.tele2.net का उपयोग किया (अंत में, एप्लिकेशन लॉन्च कमांड इस तरह दिखता है: ncftp.exe speedtest.tele2.net );
सर्वर से फाइल डाउनलोड करना। स्थानीय रूप से, एक ही नाम वाली फ़ाइल लेकिन विभिन्न गुणों के साथ पहले से मौजूद होना चाहिए। उदाहरण के लिए, आप सर्वर से एक फ़ाइल डाउनलोड कर सकते हैं, इसे बदल सकते हैं, और डाउनलोड कमांड को फिर से निष्पादित करने का प्रयास कर सकते हैं (उदाहरण के लिए, 512KB.zip प्राप्त करें );
चरित्र 'एन' के साथ शुरू होने वाली एक पंक्ति के साथ कार्रवाई चुनने के बारे में सवाल का जवाब दें (उदाहरण के लिए, अब चलो कुछ मज़ा है );
'\ 0' दर्ज करें (या कुछ और दिलचस्प);
....
लाभ!

समस्या का प्रजनन वीडियो पर भी दर्ज किया गया है:

OpenLDAP

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

कोड स्निपेट:

 int main( int argc, char **argv ) { char buf[ 4096 ]; FILE *fp = NULL; .... if (....) { fp = stdin; } .... if ( fp == NULL ) { .... } else { while ((rc == 0 || contoper) && fgets(buf, sizeof(buf), fp) != NULL) { buf[ strlen( buf ) - 1 ] = '\0'; /* remove trailing newline */ if ( *buf != '\0' ) { rc = dodelete( ld, buf ); if ( rc != 0 ) retval = rc; } } } .... }

PVS-Studio चेतावनी : V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग सूचकांक में किया जाता है: 'strlen (buf')।

हम अतिरिक्त को बाहर फेंक देते हैं ताकि समस्या का सार अधिक स्पष्ट हो जाए:

 while (.... && fgets(buf, sizeof(buf), fp) != NULL) { buf[ strlen( buf ) - 1 ] = '\0'; .... }

यह कोड NcFTP से बेहतर है, लेकिन अभी भी असुरक्षित है। यदि अनुरोध पर इनपुट के लिए शून्य लंबाई की एक स्ट्रिंग पारित करने के लिए फिट बैठता है:

fgets (buf, ....) -> buf ;
fgets (....)! = NULL -> सच ( जबकि लूप का शरीर निष्पादित करना शुरू करता है);
strlen (buf) - 1 -> 0 - 1 -> -1 ;
buf [-1] = '\ 0' ।

libidn

इस तथ्य के बावजूद कि ऊपर चर्चा की गई त्रुटियाँ काफी दिलचस्प हैं (वे निश्चित रूप से पुन: पेश की जाती हैं, और उन्हें "छुआ जा सकता है" (सिवाय इसके कि मैं OpenLDAP समस्या पर अपने हाथों तक नहीं पहुंच सकता)), उन्हें कमजोरियां नहीं कहा जा सकता है, यदि केवल इसलिए समस्याओं को सीवीई पहचानकर्ता नहीं सौंपा गया है।

हालाँकि, कुछ वास्तविक भेद्यताओं का एक ही समस्या पैटर्न होता है। नीचे दिए गए दोनों कोड स्निपेट, लिबिडन प्रोजेक्ट पर लागू होते हैं।

कोड स्निपेट:

 int main (int argc, char *argv[]) { .... else if (fgets (readbuf, BUFSIZ, stdin) == NULL) { if (feof (stdin)) break; error (EXIT_FAILURE, errno, _("input error")); } if (readbuf[strlen (readbuf) - 1] == '\n') readbuf[strlen (readbuf) - 1] = '\0'; .... }

PVS-Studio चेतावनी : V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग इंडेक्स में किया जाता है: 'strlen (readbuf)'।

स्थिति समान है, सिवाय इसके कि, पिछले उदाहरणों के विपरीत, जहां रिकॉर्डिंग इंडेक्स -1 में की गई थी , यहां रीडिंग होती है। हालाँकि, यह अभी भी अपरिभाषित व्यवहार है। इस त्रुटि को अपना स्वयं का CVE पहचानकर्ता ( CVE-2015-8948 ) सौंपा गया है।

किसी समस्या का पता लगाने के बाद, इस कोड को इस प्रकार बदला गया:

 int main (int argc, char *argv[]) { .... else if (getline (&line, &linelen, stdin) == -1) { if (feof (stdin)) break; error (EXIT_FAILURE, errno, _("input error")); } if (line[strlen (line) - 1] == '\n') line[strlen (line) - 1] = '\0'; .... }

थोड़ा आश्चर्य हुआ? ऐसा होता है। नई भेद्यता, संबंधित CVE पहचानकर्ता: CVE-2016-6262 ।

PVS-Studio चेतावनी : V1010 CWE-20 अनियंत्रित दागी डेटा का उपयोग इंडेक्स में किया जाता है: 'स्ट्रलेन (लाइन)'।

एक और प्रयास पर, इनपुट स्ट्रिंग की लंबाई के लिए एक चेक जोड़कर समस्या को ठीक किया गया था:

 if (strlen (line) > 0) if (line[strlen (line) - 1] == '\n') line[strlen (line) - 1] = '\0';

आइए तारीखों पर एक नज़र डालें। 'क्लोजिंग' CVE-2015-8948 - 08/10/2015 सीवीई-2016-62-62 - 01/14/2016 को बंद करें। यही है, उपरोक्त सुधारों के बीच का अंतर 5 महीने है ! यहाँ आपको कोड लिखने के शुरुआती चरणों में त्रुटियों का पता लगाने के रूप में स्थैतिक विश्लेषण के ऐसे लाभ के बारे में याद है ...

स्थैतिक विश्लेषण और सुरक्षा

कोई और कोड उदाहरण नहीं होगा, इसके बजाय, आंकड़े और तर्क। इस खंड में, लेखक की राय इस लेख में पहले की तुलना में पाठक की राय के साथ मेल नहीं खा सकती है।

नोट। मेरा सुझाव है कि आप इसी तरह के विषय पर एक और लेख पढ़ें - " कमजोरियों को खोजने में पीवीएस-स्टूडियो कैसे मदद कर सकता है? "। कमजोरियों के दिलचस्प उदाहरण हैं जो सरल त्रुटियों की तरह दिखते हैं। इसके अतिरिक्त, उस लेख में मैंने शब्दावली के बारे में थोड़ी बात की और स्थैतिक विश्लेषण क्यों जरूरी है यदि आप सुरक्षा विषय के बारे में चिंतित हैं।

आइए स्थिति का आकलन करने के लिए पिछले 10 वर्षों में खोजी गई कमजोरियों की संख्या पर आंकड़े देखें। मैंने सीवीई विवरण वेबसाइट से डेटा लिया।

चित्र 2

एक दिलचस्प स्थिति है। 2014 तक, दर्ज किए गए सीवीई की संख्या 6,000 इकाइयों के निशान से अधिक नहीं थी, और इससे शुरू - यह नीचे नहीं गिरा था। लेकिन यहां सबसे दिलचस्प, निश्चित रूप से, 2017 के लिए आंकड़े हैं - पूर्ण नेता (14,714 इकाइयां)। वर्तमान के रूप में - 2018 - वर्ष के लिए, यह अभी तक समाप्त नहीं हुआ है, लेकिन पहले से ही रिकॉर्ड तोड़ रहा है - 15,310 इकाइयां।

क्या इसका मतलब यह है कि सभी नए सॉफ्टवेयर छलनी की तरह छेद से भरे हुए हैं? मुझे नहीं लगता, और यहाँ क्यों है:

कमजोरियों के विषय में रुचि बढ़ गई। निश्चित रूप से, भले ही आप सुरक्षा के विषय के बहुत करीब न हों, आप बार-बार सुरक्षा के विषय पर लेख, नोट्स, रिपोर्ट और वीडियो भरते आए हैं। दूसरे शब्दों में, एक प्रकार का "प्रचार" बनाया गया था। क्या यह बुरा है? शायद नहीं। अंत में, यह सभी इस तथ्य से नीचे आता है कि डेवलपर्स आवेदन सुरक्षा के बारे में अधिक चिंतित हैं, जो अच्छा है।
विकसित अनुप्रयोगों की संख्या में वृद्धि। अधिक कोड - किसी भी भेद्यता होने की अधिक संभावना है जो आंकड़ों को फिर से भर देगी।
बेहतर भेद्यता खोज उपकरण और कोड गुणवत्ता आश्वासन। अधिक मांग -> अधिक आपूर्ति। एनालाइज़र, फ़ज़र्स और अन्य उपकरण अधिक उन्नत होते जा रहे हैं, जो उन लोगों के हाथों में खेलते हैं जो कमजोरियों की तलाश करना चाहते हैं (चाहे वे जिस भी बैरीकेड के किनारे हों)।

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

क्या इसका मतलब यह है कि आप आराम कर सकते हैं और "स्नान" नहीं कर सकते हैं? मुझे नहीं लगता। यदि आप अपने अनुप्रयोगों के सुरक्षा विषय के बारे में चिंतित हैं, तो आपको यथासंभव अधिक सुरक्षा उपाय करने चाहिए। यह विशेष रूप से सच है यदि स्रोत कोड सार्वजनिक डोमेन में है, जैसा कि यह है:

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

मैं यह नहीं कहना चाहता कि आपको अपनी परियोजनाओं को खुले स्रोत के तहत अनुवाद करने की आवश्यकता नहीं है। बस उचित गुणवत्ता / सुरक्षा नियंत्रण को ध्यान में रखें।

क्या स्थैतिक विश्लेषण ऐसा अतिरिक्त उपाय है? हां। स्थैतिक विश्लेषण संभावित कमजोरियों का पता लगाने का एक अच्छा काम करता है जो भविष्य में वास्तविक बन सकते हैं।

यह मुझे लगता है (मैं मानता हूं कि मैं गलत हूं) कि कई कमजोरियों को काफी उच्च-स्तरीय घटना मानते हैं। हाँ और नहीं। सरल प्रोग्रामिंग त्रुटियों की तरह प्रतीत होने वाली कोड समस्याएं भी गंभीर कमजोरियां हो सकती हैं। फिर, इस तरह की कमजोरियों के कुछ उदाहरण पहले उल्लिखित लेख में दिए गए हैं । 'सरल' गलतियों को कम मत समझना।

निष्कर्ष

यह मत भूलो कि इनपुट डेटा शून्य लंबाई का हो सकता है, और इसे भी ध्यान में रखना होगा।

इस बारे में निष्कर्ष कि क्या कमजोरियों के साथ सभी प्रचार सिर्फ प्रचार है, या यदि समस्या मौजूद है, तो इसे स्वयं करें।

मेरे हिस्से के लिए, जब तक कि मैं आपके प्रोजेक्ट पीवीएस-स्टूडियो पर प्रयास करने का प्रस्ताव नहीं देता, अगर आपने पहले से ऐसा नहीं किया है।

ऑल द बेस्ट!

यदि आप इस लेख को अंग्रेजी बोलने वाले दर्शकों के साथ साझा करना चाहते हैं, तो कृपया अनुवाद के लिंक का उपयोग करें: सर्गेई वासिलिव। इनपुट डेटा को हैंडल करते समय अपने आप को पैर में गोली मार लें

हम पैर में गोली मारते हैं, इनपुट डेटा को संसाधित करते हैं