2019 की शुरुआत के साथ, अतीत को याद करना और भविष्य के बारे में सोचना अच्छा है। आइए 30 साल पीछे देखें और फ़ज़िंग पर पहले वैज्ञानिक लेखों को प्रतिबिंबित करें: "यूनिक्स यूटिलिटीज की विश्वसनीयता का एक अनुभवजन्य अध्ययन" और बाद में 1995 में एक ही लेखक बार्टन मिलर द्वारा "फ़िज़िंग का पुनरीक्षण" कार्य।

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

संक्षिप्त समीक्षा

उन लोगों के लिए जिन्होंने दस्तावेजों को नहीं पढ़ा है (हालांकि यह वास्तव में किया जाना चाहिए), इस खंड में एक संक्षिप्त सारांश और कुछ चयनित उद्धरण शामिल हैं।

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

1990 के एक लेख में चार प्रोसेसर आर्किटेक्चर (i386, CVAX, Sparc, 68020) और पांच ऑपरेटिंग सिस्टम (4.3 BSD, SunOS, AIX, Xenix, Dynix) का परीक्षण किया गया। 1995 के एक लेख में, प्लेटफार्मों का एक समान विकल्प। पहले लेख में, 25-33% उपयोगिताओं में विफल रहता है, प्लेटफॉर्म पर निर्भर करता है। बाद के लेख में, ये संख्या 9% से 33% तक होती है, जिसमें GNU (SunOS पर) और लिनक्स में सबसे कम विफलता दर होती है।

1990 के एक लेख ने निष्कर्ष निकाला कि 1) प्रोग्रामर सरणी सीमाओं या त्रुटि कोड की जांच नहीं करते हैं, 2) मैक्रोज़ को कोड पढ़ना और डिबग करना मुश्किल है, और 3) सी बहुत असुरक्षित है। अत्यंत असुरक्षित कार्य gets है और टाइप सी का विशेष रूप से उल्लेख किया गया है। परीक्षण के दौरान, लेखकों ने पाया कि स्ट्रिंग स्ट्रिंग कमजोरियों से उनकी शारीरिक शोषण से सालों पहले। लेख उपयोगकर्ताओं के सर्वेक्षण के साथ निष्कर्ष निकालता है कि वे कितनी बार बग को ठीक करते हैं या उन्हें रिपोर्ट करते हैं। यह पता चला कि रिपोर्टिंग बग मुश्किल था और उन्हें ठीक करने में बहुत कम रुचि थी।

1995 के एक लेख में ओपन सोर्स सॉफ्टवेयर का उल्लेख किया गया है और चर्चा की गई है कि इसमें कम त्रुटियां क्यों हैं। उद्धरण:

जब हमने विफलताओं के कारणों की जांच की, तो एक परेशान घटना दिखाई दी: 1990 में रिपोर्ट किए गए कई कीड़े (लगभग 40%) अभी भी 1995 में अपने सटीक रूप में मौजूद हैं। ...

यहां उपयोग की जाने वाली विधियां सरल और अधिकतर स्वचालित हैं। यह समझना कठिन है कि डेवलपर विश्वसनीयता बढ़ाने के लिए इस आसान और मुक्त स्रोत का उपयोग क्यों नहीं करते हैं।

केवल 15-20 वर्षों में बड़े विक्रेताओं के लिए फ़ज़िंग तकनीक मानक अभ्यास बन जाएगी।

यह मुझे भी लगता है कि यह 1990 का बयान भविष्य की घटनाओं की भविष्यवाणी करता है:

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

परीक्षण पद्धति

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

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

30 साल में उपयोगिता बदल जाती है

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

• cfe C cc1 : 1995 के लेख से C प्रीप्रोसेसर के बराबर।
• dbx b gdb : 1995 डिबगर के बराबर।
• ditroff groff : ditroff अब उपलब्ध नहीं है।
• dtbl gtbl : पुराने dtbl उपयोगिता के GNU gtbl बराबर।
• lisp clisp : lisp का मानक कार्यान्वयन।
• more less : कम अधिक है!
• prolog swipl : prolog के लिए दो विकल्प हैं: SWI Prolog और GNU Prolog। SWI प्रोलॉग बेहतर है क्योंकि यह एक पुराना और अधिक पूर्ण कार्यान्वयन है।
• awk k gawk : GNU का संस्करण awk ।
• cc c gcc : मानक C संकलक।
• compress concept gzip : gzip पुरानी compress यूनिक्स उपयोगिता का वैचारिक वंशज है।
• lint the splint : जीपीएल के तहत लिखित lint ।
• /bin/mail r /usr/bin/mail : एक अलग तरीके से समान उपयोगिता।
• f77 fort77 : Fortan77 संकलक के दो रूपांतर हैं: GNU Fortran और Fort77। पहला फोरट्रान 90 के लिए अनुशंसित है, और दूसरा फोरट्रान77 समर्थन के लिए। f2c कार्यक्रम सक्रिय रूप से समर्थित है; इसके परिवर्तनों की सूची 1989 के बाद से बनी हुई है।

परिणाम

1989 की फ़ज़िंग तकनीक अभी भी 2018 में त्रुटियों को ढूंढती है। लेकिन कुछ प्रगति है।

प्रगति को मापने के लिए, आपको कुछ आधार चाहिए। सौभाग्य से, लिनक्स उपयोगिताओं के लिए ऐसा ढांचा मौजूद है। हालांकि 1990 में मूल लेख के समय लिनक्स मौजूद नहीं था, 1995 में एक दूसरे परीक्षण ने 1995 के स्लैकवेयर 2.1.0 वितरण से उपयोगिताओं पर एक ही फ़ज़िंग कोड लॉन्च किया। इसी परिणाम 1995 के लेख (पृष्ठ 7-9) की तालिका 3 में दिए गए हैं। वाणिज्यिक प्रतियोगियों की तुलना में, GNU / Linux बहुत अच्छा लगता है:

यूनिक्स के मुफ्त लिनक्स संस्करण में उपयोगिता दुर्घटनाओं का प्रतिशत सबसे अधिक था: 9%।

तो, आइए १ ९९ ५ और २०१ Linux के लिनक्स उपयोगिताओं की तुलना १ ९ Linux ९ के फ़ज़िंग टूल्स से करें:

	Ubuntu 18.10 (2018)	Ubuntu 18.04 (2018)	Ubuntu 16.04 (2016)	Ubuntu 14.04 (2014)	स्लैकवेयर 2.1.0 (1995)
विफलताओं	1 (f77)	1 (f77)	2 (f77, ul)	2 (swipl, f77)	4 (उल, फ्लेक्स, इंडेंट, जीडीबी)
लाकअप	1 (वर्तनी)	1 (वर्तनी)	1 (वर्तनी)	2 (वर्तनी, इकाइयाँ)	1 (ctags)
कुल परीक्षण किया गया	81	81	81	81	55
विफलताओं / फ्रीज,%	2%	2%	4%	5%	9%

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

क्या कीड़े?

मैं मैन्युअल रूप से कुछ बग्स के मूल कारण का पता लगाने में सक्षम था। कुछ परिणाम, जैसे कि एक ग्लिबक त्रुटि, अप्रत्याशित थे, जबकि अन्य, जैसे कि एक निश्चित आकार के बफर के साथ स्प्रिंटफ, पूर्वानुमान योग्य थे।

उल असफलता

उल में बग वास्तव में glibc में एक बग है। विशेष रूप से, यह यहां और यहां बताया गया था (एक अन्य व्यक्ति ने इसे ul में पाया) 2016 में। बग ट्रैकर के अनुसार, त्रुटि अभी भी तय नहीं है। चूंकि बग को Ubuntu 18.04 और बाद में पुन: प्रस्तुत नहीं किया जा सकता है, इसलिए इसे वितरण स्तर पर तय किया गया है। बग ट्रैकर पर टिप्पणियों को देखते हुए, मुख्य समस्या बहुत गंभीर हो सकती है।

क्रैश f77

f77 प्रोग्राम Fort77 पैकेज में आता है, जो कि खुद f2c आसपास एक शेल स्क्रिप्ट है, Fortran77 से C. के स्रोत अनुवादक ने F2c को डिबगिंग से पता चलता है कि विफलता तब होती है जब errstr फ़ंक्शन एक त्रुटि संदेश को प्रिंट करता है जो बहुत लंबा होता है। F2c स्रोत कोड से पता चलता है कि स्प्रिंट फ़ंक्शन का उपयोग चर-लंबाई स्ट्रिंग को निश्चित-आकार के बफर में लिखने के लिए किया जाता है:

 errstr(const char *s, const char *t) #endif { char buff[100]; sprintf(buff, s, t); err(buff); } 

ऐसा लगता है कि इस कोड को f2c के निर्माण के बाद से संरक्षित किया गया है। कार्यक्रम में कम से कम 1989 से परिवर्तन का इतिहास है । 1995 में, जब फिर से फजिंग हुई, तो फोरट्रान 77 कंपाइलर का परीक्षण नहीं किया गया, अन्यथा समस्या पहले ही मिल जाती।

फ्रीज मंत्र

क्लासिक गतिरोध का एक बड़ा उदाहरण। spell एक पाइप के माध्यम ispell । spell पाठ पंक्ति को पंक्ति से पढ़ता है और ispell में पंक्ति के आकार का एक अवरुद्ध रिकॉर्ड ispell । हालाँकि, ispell एक समय में अधिकतम BUFSIZ/2 बाइट्स (मेरे सिस्टम पर 4096 बाइट्स) को पढ़ता है और यह सुनिश्चित करने के लिए एक अवरुद्ध रिकॉर्ड जारी करता है कि क्लाइंट को सत्यापन डेटा प्राप्त हुआ है जिसे अब तक संसाधित किया गया है। दो अलग-अलग परीक्षण इनपुट ने spell को मजबूर किया जो कि ispell लिए 4096 से अधिक वर्णों की एक स्ट्रिंग लिखने के लिए है, जिसके परिणामस्वरूप गतिरोध है: spell ispell पूरे स्ट्रिंग ispell पढ़ने के लिए प्रतीक्षा करती है, जबकि ispell spell प्रतीक्षा करता है ताकि यह पुष्टि spell सके कि उसने मूल वर्तनी सुधार पढ़ा है।

हैंग यूनिट्स

पहली नज़र में, ऐसा लगता है कि एक अनंत लूप की स्थिति है। libreadline में हैंग लगता है और units में नहीं, हालांकि units नए वर्जन इस त्रुटि से ग्रस्त नहीं होते हैं। परिवर्तन लॉग इंगित करता है कि इनपुट फ़िल्टरिंग जोड़ा गया है जो गलती से इस समस्या को ठीक कर सकता है। हालांकि, कारणों की गहन जांच इस ब्लॉग के दायरे से परे है। शायद libreadline को लटकाने का तरीका अभी भी है।

स्वाइप क्रैश

पूर्णता के लिए, मैं swipl क्रैश का उल्लेख करना चाहता हूं, हालांकि मैंने इसका सावधानीपूर्वक अध्ययन नहीं किया है, क्योंकि बग लंबे समय से तय किया गया है और काफी उच्च गुणवत्ता वाला लगता है। असफलता वास्तव में एक कथन है (यानी ऐसा जो कभी नहीं होना चाहिए) जिसे वर्ण परिवर्तित करते समय कहा जाता है:

[Thread 1] pl-fli.c:2495: codeToAtom: Assertion failed: chrcode >= 0
C-stack trace labeled "crash":
[0] __assert_fail+0x41
[1] PL_put_term+0x18e
[2] PL_unify_text+0x1c4
…

दुर्घटना हमेशा खराब होती है, लेकिन कम से कम यहां कार्यक्रम त्रुटि की सूचना दे सकता है, जल्दी और जोर से दुर्घटनाग्रस्त हो सकता है।

निष्कर्ष

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

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

आशा है कि आपको यह 30 साल पूर्वव्यापी पसंद आया। अगले "2000 में फ़ज़िंग" लेख के लिए प्रतीक्षा करें, जहां हम जांच करेंगे कि फ़्यूज़र के साथ परीक्षण किए जाने पर विंडोज 10 एप्लिकेशन उनके विंडोज एनटी / 2000 समकक्षों की तुलना में कितने मजबूत हैं। मुझे लगता है कि उत्तर अनुमानित है।