फज़िंग: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 15: | Line 15: | ||
* 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है। | * 1995:<ref name="fuzz1995"/>फ़ज़ रिविज़िटेड पेपर में चार भाग होते है। | ||
*# यूनिक्स उपकरण की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स उपकरण की तुलना में काफी अधिक विश्वसनीय थे। | *# यूनिक्स उपकरण की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स [[जीएनयू]] और [[लिनक्स]] उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स उपकरण की तुलना में काफी अधिक विश्वसनीय थे। | ||
*# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे | *# एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे एक्स विंडोज अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था। | ||
*# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी। | *# संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी। | ||
*# उपकरण लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहे। | *# उपकरण लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहे। | ||
* 2000:<ref name="fuzz2000"/>हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग उपकरण के लिए एप्लाइड फज़ परीक्षण, [[Win32]] विंडो उपकरण के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम | * 2000:<ref name="fuzz2000"/>हाल ही में जारी किए गए [[विंडोज एनटी]] ऑपरेटिंग उपकरण के लिए एप्लाइड फज़ परीक्षण, [[Win32]] विंडो उपकरण के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया। | ||
* 2001:<ref>{{cite web|url=https://pages.cs.wisc.edu/~blbowers/fuzz-2001.pdf|title=UNIX उपयोगिताओं की स्थिरता और विश्वसनीयता की जांच|website=cs.wisc.edu|access-date=3 March 2023}}</ref> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक | * 2001:<ref>{{cite web|url=https://pages.cs.wisc.edu/~blbowers/fuzz-2001.pdf|title=UNIX उपयोगिताओं की स्थिरता और विश्वसनीयता की जांच|website=cs.wisc.edu|access-date=3 March 2023}}</ref> दो लोकप्रिय यूनिक्स वेरिएंट्स, एक जीएनयू/लिनक्स प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया। | ||
* 2006:<ref name="fuzz2006"/>कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X | | * 2006:<ref name="fuzz2006"/>कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए [[ Mac OS X |मैक ओएस एक्स]] पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने मैक ओएस Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो उपकरण के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए। | ||
* 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स उपकरण, विशेष रूप से Linux, [[FreeBSD]] और | * 2020:<ref name="fuzz2020"/>हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स उपकरण, विशेष रूप से Linux, [[FreeBSD|फ्री बीएसडी]] और मैक ओएस पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई यूनिक्स उपयोगिताओं का भी परीक्षण किया और पाया कि वे सी में लिखी गई समान विश्वसनीयता की थीं, हालांकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी। | ||
अप्रैल 2012 में, | अप्रैल 2012 में, गूगल ने [[क्रोमियम वेब ब्राउज़र]] के सुरक्षा-महत्वपूर्ण घटकों के लिए क्लाउड-आधारित फ़ज़िंग इंफ्रास्ट्रक्चर क्लस्टरफ़ज़ की घोषणा की।<ref name="clusterfuzz"/> यदि क्लस्टरफ़ज़ को अपलोड किए गए फ़ज़र के साथ क्रैश होने का पता चलता है, तो सुरक्षा शोधकर्ता अपने स्वयं के फ़ज़र्स अपलोड कर सकते है और बग बाउंटी एकत्र कर सकते है। | ||
सितंबर 2014 में, [[शेलशॉक (सॉफ्टवेयर बग)]]<ref name="NYT-20140925-NP">{{cite news |last=Perlroth |first=Nicole |title=सुरक्षा विशेषज्ञ बैश में 'शेलशॉक' सॉफ्टवेयर बग के महत्वपूर्ण होने की अपेक्षा करते हैं|url=https://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html |date=25 September 2014 |work=[[The New York Times]] |access-date=25 September 2014}}</ref> व्यापक रूप से उपयोग किए जाने वाले यूनिक्स [[बैश (यूनिक्स शेल)]] [[ खोल (कंप्यूटिंग) |खोल (कंप्यूटिंग)]] में [[सुरक्षा बग]] | सितंबर 2014 में, [[शेलशॉक (सॉफ्टवेयर बग)]]<ref name="NYT-20140925-NP">{{cite news |last=Perlroth |first=Nicole |title=सुरक्षा विशेषज्ञ बैश में 'शेलशॉक' सॉफ्टवेयर बग के महत्वपूर्ण होने की अपेक्षा करते हैं|url=https://www.nytimes.com/2014/09/26/technology/security-experts-expect-shellshock-software-bug-to-be-significant.html |date=25 September 2014 |work=[[The New York Times]] |access-date=25 September 2014}}</ref> व्यापक रूप से उपयोग किए जाने वाले यूनिक्स [[बैश (यूनिक्स शेल)]] [[ खोल (कंप्यूटिंग) |खोल (कंप्यूटिंग)]] में [[सुरक्षा बग|सुरक्षा बगों]] के परिवार के रूप में खुलासा किया गया था; शेलशॉक की अधिकांश भेद्यताएं [[अमेरिकन फ़ज़ी लोप (फ़ज़र)]]फ़ज़र) का उपयोग करके पाई गईं।<ref>{{cite web|url=http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html|title=Bash bug: the other two RCEs, or how we chipped away at the original fix (CVE-2014-6277 and '78)|date=1 October 2014|website=lcamtuf's blog|last1=Zalewski|first1=Michał|access-date=13 March 2017}}</ref> (कई इंटरनेट-फेसिंग सेवाएं, जैसे कि कुछ वेब सर्वर परिनियोजन, कुछ अनुरोधों को संसाधित करने के लिए बैश का उपयोग करती है, एक हमलावर को [[मनमाना कोड निष्पादन]] के लिए बैश के कमजोर संस्करणों का कारण बनने की अनुमति देती है। यह एक हमलावर को कंप्यूटर उपकरण पर अनधिकृत पहुंच प्राप्त करने की अनुमति दे सकता है।<ref name="ZDN-20140929">{{cite web|last=Seltzer |first=Larry |title=शेलशॉक हार्टब्लीड को महत्वहीन बना देता है|url=http://www.zdnet.com/shellshock-makes-heartbleed-look-insignificant-7000034143/ |date=29 September 2014 |publisher=[[ZDNet]] |access-date=29 September 2014}}</ref>) | ||
अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था।<ref>{{cite web|last1=Böck|first1=Hanno|title=Fuzzing: Wie man Heartbleed hätte finden können (in German)|url=http://www.golem.de/news/fuzzing-wie-man-heartbleedhaette-finden-koennen-1504-113345.html|website=Golem.de|access-date=13 March 2017|language=de-DE}}</ref><ref>{{cite web|last1=Böck|first1=Hanno|title=हार्टब्लीड कैसे पाया जा सकता था (अंग्रेज़ी में)|url=https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html|website=Hanno's blog|access-date=13 March 2017}}</ref> (अप्रैल 2014 में [[ हार्दिक |हार्दिक]] भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा [[एन्क्रिप्टेड संचार]] को समझने की अनुमति देती है। भेद्यता को गलती से [[ओपनएसएसएल]] में पेश किया गया था जो [[ परिवहन परत सुरक्षा |परिवहन परत सुरक्षा]] को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। [[शोडान (वेबसाइट)]] ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी;<ref>{{cite web|url=https://www.shodan.io/report/89bnfUyJ|title=Search engine for the internet of things – devices still vulnerable to Heartbleed|website=shodan.io|access-date=13 March 2017}}</ref> जनवरी 2017 में 200,000।<ref>{{cite web|url=https://www.shodan.io/report/DCPO7BkV|title=Heartbleed Report (2017-01)|website=shodan.io|access-date=10 July 2017}}</ref>) | अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था।<ref>{{cite web|last1=Böck|first1=Hanno|title=Fuzzing: Wie man Heartbleed hätte finden können (in German)|url=http://www.golem.de/news/fuzzing-wie-man-heartbleedhaette-finden-koennen-1504-113345.html|website=Golem.de|access-date=13 March 2017|language=de-DE}}</ref><ref>{{cite web|last1=Böck|first1=Hanno|title=हार्टब्लीड कैसे पाया जा सकता था (अंग्रेज़ी में)|url=https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html|website=Hanno's blog|access-date=13 March 2017}}</ref> (अप्रैल 2014 में [[ हार्दिक |हार्दिक]] भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा [[एन्क्रिप्टेड संचार]] को समझने की अनुमति देती है। भेद्यता को गलती से [[ओपनएसएसएल]] में पेश किया गया था जो [[ परिवहन परत सुरक्षा |परिवहन परत सुरक्षा]] को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। [[शोडान (वेबसाइट)]] ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी;<ref>{{cite web|url=https://www.shodan.io/report/89bnfUyJ|title=Search engine for the internet of things – devices still vulnerable to Heartbleed|website=shodan.io|access-date=13 March 2017}}</ref> जनवरी 2017 में 200,000।<ref>{{cite web|url=https://www.shodan.io/report/DCPO7BkV|title=Heartbleed Report (2017-01)|website=shodan.io|access-date=10 July 2017}}</ref>) | ||
| Line 31: | Line 31: | ||
अगस्त 2016 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (DARPA) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया, जो पूरी तरह से स्वचालित कैप्चर द फ़्लैग (साइबर सुरक्षा) | कैप्चर-द-फ़्लैग प्रतियोगिता थी जो 11 घंटे तक चली।<ref name="cgc">{{cite web|url=http://www.darpa.mil/program/cyber-grand-challenge |title= DARPA साइबर ग्रैंड चैलेंज|last=Walker |first=Michael |website=darpa.mil |access-date=12 March 2017}}</ref> इसका उद्देश्य स्वचालित रक्षा प्रणालियों को विकसित करना था जो [[रीयल-टाइम कंप्यूटिंग]] | रीयल-टाइम में सॉफ़्टवेयर त्रुटियों की खोज, [[शोषण (कंप्यूटर सुरक्षा)]], और [[स्वचालित बग फिक्सिंग]] सॉफ़्टवेयर त्रुटियों को विकसित कर सके। विरोधियों के सॉफ्टवेयर में खामियों को खोजने के लिए फ़ज़िंग को एक प्रभावी अपराध रणनीति के रूप में इस्तेमाल किया गया था। इसने भेद्यता का पता लगाने के स्वचालन में जबरदस्त क्षमता दिखाई। विजेता हाथापाई नामक एक प्रणाली थी<ref name="2016 results">{{cite web|url=http://www.darpa.mil/news-events/2016-08-05a |title=तबाही सीजीसी में पहले स्थान पर आती है|access-date=12 March 2017}}</ref> [[डेविड ब्रमली]] के नेतृत्व वाली टीम फॉरऑलसिक्योर द्वारा विकसित किया गया। | अगस्त 2016 में, [[रक्षा अग्रिम जाँच परियोजनाएं एजेंसी]] (DARPA) ने पहले [[साइबर ग्रैंड चैलेंज]] का फाइनल आयोजित किया, जो पूरी तरह से स्वचालित कैप्चर द फ़्लैग (साइबर सुरक्षा) | कैप्चर-द-फ़्लैग प्रतियोगिता थी जो 11 घंटे तक चली।<ref name="cgc">{{cite web|url=http://www.darpa.mil/program/cyber-grand-challenge |title= DARPA साइबर ग्रैंड चैलेंज|last=Walker |first=Michael |website=darpa.mil |access-date=12 March 2017}}</ref> इसका उद्देश्य स्वचालित रक्षा प्रणालियों को विकसित करना था जो [[रीयल-टाइम कंप्यूटिंग]] | रीयल-टाइम में सॉफ़्टवेयर त्रुटियों की खोज, [[शोषण (कंप्यूटर सुरक्षा)]], और [[स्वचालित बग फिक्सिंग]] सॉफ़्टवेयर त्रुटियों को विकसित कर सके। विरोधियों के सॉफ्टवेयर में खामियों को खोजने के लिए फ़ज़िंग को एक प्रभावी अपराध रणनीति के रूप में इस्तेमाल किया गया था। इसने भेद्यता का पता लगाने के स्वचालन में जबरदस्त क्षमता दिखाई। विजेता हाथापाई नामक एक प्रणाली थी<ref name="2016 results">{{cite web|url=http://www.darpa.mil/news-events/2016-08-05a |title=तबाही सीजीसी में पहले स्थान पर आती है|access-date=12 March 2017}}</ref> [[डेविड ब्रमली]] के नेतृत्व वाली टीम फॉरऑलसिक्योर द्वारा विकसित किया गया। | ||
सितंबर 2016 में, | सितंबर 2016 में, माइक्रोसॉफ्ट ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।<ref name="springfield"/> | ||
दिसंबर 2016 में, | दिसंबर 2016 में, गूगल ने ओएसएस-फ़ज़ की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।<ref name="ossfuzz"/> | ||
ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था। | ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया।<ref name ="domas"/> यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था। | ||
| Line 44: | Line 44: | ||
रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण |यादृच्छिक परीक्षण]] या [[ बंदर परीक्षण |बंदर परीक्षण]] भी कहा जाता है। | रैंडम इनपुट के निष्पादन को [[ यादृच्छिक परीक्षण |यादृच्छिक परीक्षण]] या [[ बंदर परीक्षण |बंदर परीक्षण]] भी कहा जाता है। | ||
1981 में, डुरान और | 1981 में, डुरान और नताफोस ने औपचारिक रूप से यादृच्छिक इनपुट के साथ एक कार्यक्रम के परीक्षण की प्रभावशीलता की जांच की।<ref name="duran1"/><ref name="duran2"/>जबकि यादृच्छिक परीक्षण व्यापक रूप से एक कार्यक्रम के परीक्षण का सबसे खराब साधन माना जाता था, लेखक यह दिखा सकते थे कि यह अधिक व्यवस्थित परीक्षण तकनीकों के लिए एक लागत प्रभावी विकल्प है। | ||
1983 में, Apple में [[स्टीव कैप्स]] ने द मंकी को विकसित किया,<ref name="hertzfeld2004"/>एक उपकरण जो [[मैकपेंट]] जैसे [[क्लासिक मैक ओएस]] अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा।<ref name="AutoDO-3"/>आलंकारिक बंदर [[अनंत बंदर प्रमेय]] को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा। | 1983 में, Apple में [[स्टीव कैप्स]] ने द मंकी को विकसित किया,<ref name="hertzfeld2004"/>एक उपकरण जो [[मैकपेंट]] जैसे [[क्लासिक मैक ओएस]] अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा।<ref name="AutoDO-3"/>आलंकारिक बंदर [[अनंत बंदर प्रमेय]] को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा। | ||
| Line 67: | Line 67: | ||
एक स्मार्ट (मॉडल-आधारित,<ref name="pham"/>व्याकरण आधारित,<ref name="AutoDO-14"/><ref name="peach"/>या प्रोटोकॉल आधारित<ref>{{cite conference|title=SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr|url=http://dl.acm.org/citation.cfm?id=2079962|author1=Greg Banks|author2=Marco Cova|author3=Viktoria Felmetsger|author4=Kevin Almeroth|author5=Richard Kemmerer|author6=Giovanni Vigna|publisher=Proceedings of the Information Security Conference (ISC'06)}}</ref>) फजर वैध इनपुट का अधिक अनुपात उत्पन्न करने के लिए इनपुट मॉडल का लाभ उठाता है। उदाहरण के लिए, यदि इनपुट को [[सार वाक्य रचना का पेड़]] के रूप में मॉडल किया जा सकता है, तो एक स्मार्ट म्यूटेशन-आधारित फ़ज़र<ref name="peach"/>पूर्ण सबट्री को एक नोड से दूसरे में ले जाने के लिए रैंडम [[ कार्यक्रम परिवर्तन |कार्यक्रम परिवर्तन]] को नियोजित करेगा। यदि इनपुट को एक औपचारिक व्याकरण, एक स्मार्ट पीढ़ी-आधारित फजर द्वारा तैयार किया जा सकता है<ref name="AutoDO-14"/>व्याकरण के संबंध में मान्य इनपुट उत्पन्न करने के लिए [[उत्पादन (कंप्यूटर विज्ञान)]] को तुरंत चालू करेगा। हालांकि, आम तौर पर इनपुट मॉडल को स्पष्ट रूप से प्रदान किया जाना चाहिए, जो कि मॉडल के मालिकाना, अज्ञात या बहुत जटिल होने पर करना मुश्किल है। यदि वैध और अमान्य इनपुट का एक बड़ा कोष उपलब्ध है, तो एक [[व्याकरण प्रेरण]] तकनीक, जैसे कि [[ एंग्लुइन फंड |एंग्लुइन फंड]] का एल* एल्गोरिथम, एक इनपुट मॉडल उत्पन्न करने में सक्षम होगा।<ref name="aiken"/><ref name="AutoDO-15"/> | एक स्मार्ट (मॉडल-आधारित,<ref name="pham"/>व्याकरण आधारित,<ref name="AutoDO-14"/><ref name="peach"/>या प्रोटोकॉल आधारित<ref>{{cite conference|title=SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr|url=http://dl.acm.org/citation.cfm?id=2079962|author1=Greg Banks|author2=Marco Cova|author3=Viktoria Felmetsger|author4=Kevin Almeroth|author5=Richard Kemmerer|author6=Giovanni Vigna|publisher=Proceedings of the Information Security Conference (ISC'06)}}</ref>) फजर वैध इनपुट का अधिक अनुपात उत्पन्न करने के लिए इनपुट मॉडल का लाभ उठाता है। उदाहरण के लिए, यदि इनपुट को [[सार वाक्य रचना का पेड़]] के रूप में मॉडल किया जा सकता है, तो एक स्मार्ट म्यूटेशन-आधारित फ़ज़र<ref name="peach"/>पूर्ण सबट्री को एक नोड से दूसरे में ले जाने के लिए रैंडम [[ कार्यक्रम परिवर्तन |कार्यक्रम परिवर्तन]] को नियोजित करेगा। यदि इनपुट को एक औपचारिक व्याकरण, एक स्मार्ट पीढ़ी-आधारित फजर द्वारा तैयार किया जा सकता है<ref name="AutoDO-14"/>व्याकरण के संबंध में मान्य इनपुट उत्पन्न करने के लिए [[उत्पादन (कंप्यूटर विज्ञान)]] को तुरंत चालू करेगा। हालांकि, आम तौर पर इनपुट मॉडल को स्पष्ट रूप से प्रदान किया जाना चाहिए, जो कि मॉडल के मालिकाना, अज्ञात या बहुत जटिल होने पर करना मुश्किल है। यदि वैध और अमान्य इनपुट का एक बड़ा कोष उपलब्ध है, तो एक [[व्याकरण प्रेरण]] तकनीक, जैसे कि [[ एंग्लुइन फंड |एंग्लुइन फंड]] का एल* एल्गोरिथम, एक इनपुट मॉडल उत्पन्न करने में सक्षम होगा।<ref name="aiken"/><ref name="AutoDO-15"/> | ||
एक गूंगा फजर<ref name="AutoDO-1"/><ref name="ganesh"/>इनपुट मॉडल की आवश्यकता नहीं होती है और इस प्रकार कार्यक्रमों की व्यापक विविधता को कम करने के लिए नियोजित किया जा सकता है। उदाहरण के लिए, अमेरिकन फ़ज़ी लोप (फ़ज़र) एक गूंगा म्यूटेशन-आधारित फ़ज़र है जो बिटवाइज़ ऑपरेशन द्वारा एक बीज फ़ाइल को संशोधित करता है # नहीं, दिलचस्प मूल्यों के साथ यादृच्छिक बाइट्स को प्रतिस्थापित करके, और डेटा के ब्लॉक को स्थानांतरित या हटाकर। हालांकि, एक गूंगा फजर वैध इनपुट का कम अनुपात उत्पन्न कर सकता है और प्रोग्राम के मुख्य घटकों के बजाय पार्सर कोड पर जोर दे सकता है। [[ चक्रीय अतिरिक्तता जांच |चक्रीय अतिरिक्तता जांच]] ( | एक गूंगा फजर<ref name="AutoDO-1"/><ref name="ganesh"/>इनपुट मॉडल की आवश्यकता नहीं होती है और इस प्रकार कार्यक्रमों की व्यापक विविधता को कम करने के लिए नियोजित किया जा सकता है। उदाहरण के लिए, अमेरिकन फ़ज़ी लोप (फ़ज़र) एक गूंगा म्यूटेशन-आधारित फ़ज़र है जो बिटवाइज़ ऑपरेशन द्वारा एक बीज फ़ाइल को संशोधित करता है # नहीं, दिलचस्प मूल्यों के साथ यादृच्छिक बाइट्स को प्रतिस्थापित करके, और डेटा के ब्लॉक को स्थानांतरित या हटाकर। हालांकि, एक गूंगा फजर वैध इनपुट का कम अनुपात उत्पन्न कर सकता है और प्रोग्राम के मुख्य घटकों के बजाय पार्सर कोड पर जोर दे सकता है। [[ चक्रीय अतिरिक्तता जांच |चक्रीय अतिरिक्तता जांच]] (सीआरसी) के लिए एक वैध [[ अंततः, |अंततः,]] के निर्माण के माध्यम से डंब फज़र्स के नुकसान को चित्रित किया जा सकता है। सीआरसी एक [[ त्रुटि का पता लगाने वाला कोड |त्रुटि का पता लगाने वाला कोड]] है जो यह सुनिश्चित करता है कि इनपुट फ़ाइल में निहित डेटा की डेटा अखंडता [[डेटा ट्रांसमिशन]] के दौरान संरक्षित है। एक चेकसम की गणना इनपुट डेटा पर की जाती है और फ़ाइल में दर्ज की जाती है। जब प्रोग्राम प्राप्त फ़ाइल को प्रोसेस करता है और रिकॉर्ड किया गया चेकसम पुनः गणना किए गए चेकसम से मेल नहीं खाता है, तो फ़ाइल को अमान्य के रूप में अस्वीकार कर दिया जाता है। अब, सीआरसी से अनजान एक फजर सही चेकसम उत्पन्न करने की संभावना नहीं है। हालाँकि, म्यूट म्यूटेशन-आधारित फ़ज़र द्वारा संरक्षित डेटा को संशोधित करने के बाद, उत्परिवर्तित इनपुट में एक संभावित चेकसम की पहचान करने और फिर से गणना करने का प्रयास किया जाता है।<ref>{{cite book|last1=Wang|first1=T.|last2=Wei|first2=T.|last3=Gu|first3=G.|last4=Zou|first4=W.|title=TaintScope: A Checksum-Aware Directed Fuzzing Tool for Automatic Software Vulnerability Detection|journal=2010 IEEE Symposium on Security and Privacy|date=May 2010|pages=497–512|doi=10.1109/SP.2010.37|isbn=978-1-4244-6894-2|citeseerx=10.1.1.169.7866|s2cid=11898088}}</ref> | ||
=== कार्यक्रम संरचना से अवगत === | === कार्यक्रम संरचना से अवगत === | ||
आमतौर पर, एक फ़ज़र को अधिक प्रभावी माना जाता है यदि वह उच्च स्तर का [[ कोड कवरेज़ |कोड कवरेज़]] प्राप्त करता है। तर्क यह है कि यदि कोई फ़ज़र प्रोग्राम में कुछ संरचनात्मक तत्वों का प्रयोग नहीं करता है, तो यह उन [[सॉफ्टवेयर बग]] को प्रकट करने में भी सक्षम नहीं है जो इन तत्वों में छिपे हुए है। कुछ कार्यक्रम तत्वों को दूसरों की तुलना में अधिक महत्वपूर्ण माना जाता है। उदाहरण के लिए, एक डिवीजन ऑपरेटर शून्य त्रुटि से डिवीजन का कारण बन सकता है, या [[सिस्टम कॉल|उपकरण कॉल]] प्रोग्राम को क्रैश कर सकता है। | आमतौर पर, एक फ़ज़र को अधिक प्रभावी माना जाता है यदि वह उच्च स्तर का [[ कोड कवरेज़ |कोड कवरेज़]] प्राप्त करता है। तर्क यह है कि यदि कोई फ़ज़र प्रोग्राम में कुछ संरचनात्मक तत्वों का प्रयोग नहीं करता है, तो यह उन [[सॉफ्टवेयर बग]] को प्रकट करने में भी सक्षम नहीं है जो इन तत्वों में छिपे हुए है। कुछ कार्यक्रम तत्वों को दूसरों की तुलना में अधिक महत्वपूर्ण माना जाता है। उदाहरण के लिए, एक डिवीजन ऑपरेटर शून्य त्रुटि से डिवीजन का कारण बन सकता है, या [[सिस्टम कॉल|उपकरण कॉल]] प्रोग्राम को क्रैश कर सकता है। | ||
| Line 92: | Line 92: | ||
* अपरिभाषित व्यवहार का पता लगाने के लिए (अपरिभाषित व्यवहार सैनिटाइज़र), | * अपरिभाषित व्यवहार का पता लगाने के लिए (अपरिभाषित व्यवहार सैनिटाइज़र), | ||
* मेमोरी लीक (लीकसैनिटाइज़र) का पता लगाने के लिए, या | * मेमोरी लीक (लीकसैनिटाइज़र) का पता लगाने के लिए, या | ||
*[[ नियंत्रण-प्रवाह अखंडता | नियंत्रण-प्रवाह अखंडता]] ( | *[[ नियंत्रण-प्रवाह अखंडता | नियंत्रण-प्रवाह अखंडता]] (सीएफआई सैनिटाइजर) की जांच करने के लिए। | ||
यदि कोई [[संदर्भ कार्यान्वयन]] उपलब्ध है तो अंतर बग का पता लगाने के लिए फ़ज़िंग का भी उपयोग किया जा सकता है। स्वचालित [[प्रतिगमन परीक्षण]] के लिए,<ref>{{cite book|last1=Orso|first1=Alessandro|last2=Xie|first2=Tao|title=BERT: BEhavioral Regression Testing|journal=Proceedings of the 2008 International Workshop on Dynamic Analysis (WODA 2008)|year=2008|pages=36–42|doi=10.1145/1401827.1401835|publisher=ACM|isbn=9781605580548|s2cid=7506576}}</ref> उत्पन्न इनपुट एक ही प्रोग्राम के दो [[सॉफ्टवेयर वर्जनिंग]] पर निष्पादित होते है। स्वचालित [[अंतर परीक्षण]] के लिए,<ref>{{cite journal|last1=McKeeman|first1=William M.|author-link=William M. McKeeman|title=सॉफ्टवेयर के लिए विभेदक परीक्षण|journal=Digital Technical Journal|year=1998|volume=10|issue=1|pages=100–107|url=http://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf}}</ref> जेनरेट किए गए इनपुट एक ही प्रोग्राम के दो कार्यान्वयन पर निष्पादित होते है (उदाहरण के लिए, [[ lighttpd |lighttpd]] और [[httpd]] दोनों एक वेब सर्वर के कार्यान्वयन है)। यदि दो वेरिएंट एक ही इनपुट के लिए अलग-अलग आउटपुट देते है, तो एक छोटी गाड़ी हो सकती है और इसकी अधिक बारीकी से जांच की जानी चाहिए। | यदि कोई [[संदर्भ कार्यान्वयन]] उपलब्ध है तो अंतर बग का पता लगाने के लिए फ़ज़िंग का भी उपयोग किया जा सकता है। स्वचालित [[प्रतिगमन परीक्षण]] के लिए,<ref>{{cite book|last1=Orso|first1=Alessandro|last2=Xie|first2=Tao|title=BERT: BEhavioral Regression Testing|journal=Proceedings of the 2008 International Workshop on Dynamic Analysis (WODA 2008)|year=2008|pages=36–42|doi=10.1145/1401827.1401835|publisher=ACM|isbn=9781605580548|s2cid=7506576}}</ref> उत्पन्न इनपुट एक ही प्रोग्राम के दो [[सॉफ्टवेयर वर्जनिंग]] पर निष्पादित होते है। स्वचालित [[अंतर परीक्षण]] के लिए,<ref>{{cite journal|last1=McKeeman|first1=William M.|author-link=William M. McKeeman|title=सॉफ्टवेयर के लिए विभेदक परीक्षण|journal=Digital Technical Journal|year=1998|volume=10|issue=1|pages=100–107|url=http://www.hpl.hp.com/hpjournal/dtj/vol10num1/vol10num1art9.pdf}}</ref> जेनरेट किए गए इनपुट एक ही प्रोग्राम के दो कार्यान्वयन पर निष्पादित होते है (उदाहरण के लिए, [[ lighttpd |lighttpd]] और [[httpd]] दोनों एक वेब सर्वर के कार्यान्वयन है)। यदि दो वेरिएंट एक ही इनपुट के लिए अलग-अलग आउटपुट देते है, तो एक छोटी गाड़ी हो सकती है और इसकी अधिक बारीकी से जांच की जानी चाहिए। | ||
| Line 105: | Line 105: | ||
=== स्वचालित बग ट्राइएज === | === स्वचालित बग ट्राइएज === | ||
{{Main|बग ट्राइएज}} | {{Main|बग ट्राइएज}} | ||
स्वचालित बग ट्राइएज का उपयोग बड़ी संख्या में विफलता-उत्प्रेरण इनपुट को [[मूल कारण विश्लेषण]] द्वारा समूहित करने और गंभीरता से प्रत्येक व्यक्तिगत बग को प्राथमिकता देने के लिए किया जाता है। एक फ़ज़र बड़ी संख्या में इनपुट उत्पन्न करता है, और कई विफलता-उत्प्रेरण वाले एक ही सॉफ़्टवेयर बग को प्रभावी ढंग से उजागर कर सकते है। इनमें से केवल कुछ बग सुरक्षा बग है | सुरक्षा-महत्वपूर्ण और उच्च प्राथमिकता के साथ [[पैच (कंप्यूटिंग)]] होना चाहिए। उदाहरण के लिए [[सीईआरटी समन्वय केंद्र]] लिनक्स ट्राइएज टूल प्रदान करता है जो उत्पादित [[स्टैक ट्रेस]] द्वारा क्रैशिंग इनपुट को समूहित करता है और प्रत्येक समूह को उनके शोषण की संभावना (कंप्यूटर सुरक्षा) के अनुसार सूचीबद्ध करता है।<ref>{{cite web|title=सीईआरटी ट्राइएज टूल्स|url=https://www.cert.org/vulnerability-analysis/tools/triage.cfm?|website=CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU)|access-date=14 March 2017}}</ref> | स्वचालित बग ट्राइएज का उपयोग बड़ी संख्या में विफलता-उत्प्रेरण इनपुट को [[मूल कारण विश्लेषण]] द्वारा समूहित करने और गंभीरता से प्रत्येक व्यक्तिगत बग को प्राथमिकता देने के लिए किया जाता है। एक फ़ज़र बड़ी संख्या में इनपुट उत्पन्न करता है, और कई विफलता-उत्प्रेरण वाले एक ही सॉफ़्टवेयर बग को प्रभावी ढंग से उजागर कर सकते है। इनमें से केवल कुछ बग सुरक्षा बग है | सुरक्षा-महत्वपूर्ण और उच्च प्राथमिकता के साथ [[पैच (कंप्यूटिंग)]] होना चाहिए। उदाहरण के लिए [[सीईआरटी समन्वय केंद्र]] लिनक्स ट्राइएज टूल प्रदान करता है जो उत्पादित [[स्टैक ट्रेस]] द्वारा क्रैशिंग इनपुट को समूहित करता है और प्रत्येक समूह को उनके शोषण की संभावना (कंप्यूटर सुरक्षा) के अनुसार सूचीबद्ध करता है।<ref>{{cite web|title=सीईआरटी ट्राइएज टूल्स|url=https://www.cert.org/vulnerability-analysis/tools/triage.cfm?|website=CERT Division of the Software Engineering Institute (SEI) at Carnegie Mellon University (CMU)|access-date=14 March 2017}}</ref> माइक्रोसॉफ्ट सुरक्षा अनुसंधान केंद्र (एमएसईसी) ने !शोषणीय उपकरण विकसित किया है जो पहले अपनी विशिष्टता निर्धारित करने के लिए क्रैशिंग इनपुट के लिए एक [[हैश फंकशन]] बनाता है और फिर एक शोषक रेटिंग प्रदान करता है:<ref>{{cite web|title=माइक्रोसॉफ्ट! शोषक क्रैश विश्लेषक|url=https://msecdbg.codeplex.com/|website=CodePlex|access-date=14 March 2017}}</ref> | ||
* शोषक | * शोषक | ||
*शायद शोषक | *शायद शोषक | ||
Revision as of 07:37, 23 May 2023
| श्रृंखला का हिस्सा |
| सूचना सुरक्षा |
|---|
 |
| सुरक्षा संबंधित श्रेणियां |
| थ्रेट्स |