ओपन सोर्स लाइब्रेरीज़ में पार्टनरशिप डिस्कवरी पार्ट 1: ट्रेड के उपकरण

कार्यकारी सारांश

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

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

ग्राफिक्स पुस्तकालयों में कमजोरियों का एक समृद्ध इतिहास है और शोषक मुद्दों की मात्रा विशेष रूप से बढ़ाई जाती है जब कोड आधार अपेक्षाकृत पुराना है और हाल ही में फिर से नहीं बनाया गया है। यह पता चला है कि लिनक्स पर ग्राफिक्स पुस्तकालयों का व्यापक रूप से कई अनुप्रयोगों में उपयोग किया जाता है, लेकिन सुरक्षा मुद्दों के लिए पर्याप्त रूप से ऑडिट और परीक्षण नहीं किया जाता है। यह अंततः हमारे लिए लिनक्स पर कई वेक्टर ग्राफिक्स और GDI पुस्तकालयों का परीक्षण करने के लिए एक प्रेरक शक्ति बन गया, जिनमें से एक libEMF था, एक लिनक्स C ++ पुस्तकालय जो एक समान उद्देश्य के लिए लिखा गया था और कई ग्राफिक्स टूल्स में उपयोग किया गया था जो अन्य वेक्टर प्रारूपों में ग्राफिक्स रूपांतरण का समर्थन करते हैं। हमने कई दिनों तक इस लाइब्रेरी का परीक्षण किया और कई कमजोरियों को पाया, जिसमें कई इनकार-से-सेवा के मुद्दे, पूर्णांक अतिप्रवाह, आउट-ऑफ-बाउंड मेमोरी एक्सेस, उपयोग-बाद-नि: शुल्क स्थितियां, और अनइंस्टॉल किए गए मेमोरी उपयोग शामिल हैं।

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

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

परिचय

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

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

लिनक्स पर एएफएल जैसे फ्यूल संकलक आवरण के साथ आते हैं (afl-gcc, afl-clang, आदि)। विधानसभा पार्सिंग मॉड्यूल के साथ AFL-के रूप में, एएफएल ने कोड-कवरेज को देखने में मदद करने के लिए संकलन-समय इंस्ट्रूमेंटेशन को जोड़ने के लिए उत्पन्न विधानसभा कोड को पार्स किया। इसके अतिरिक्त, आधुनिक संकलक एड्रेस सेनिटाइज़र (ASAN), मेमोरी सैनिटाइज़र (MSAN), लीक सेनिटाइज़र (LSAN), थ्रेड सेनिटाइज़र (TSAN), आदि जैसे सैनिटाइज़र मॉड्यूल के साथ आते हैं, जो फ़ज़र्स की बग ढूंढने की क्षमताओं को और बढ़ा सकते हैं। नीचे स्मृति भ्रष्टाचार बगों की विविधता पर प्रकाश डाला गया है जो फ़िज़र्स के साथ उपयोग किए जाने पर सैनिटाइज़र द्वारा खोजे जा सकते हैं।

आसन MSAN UBSAN TSAN LSAN
नि: शुल्क कमजोरियों के बाद का उपयोग करें Uninitialized मेमोरी रीड नल सूचक Dereferences दौर कि शर्ते रन टाइम मेमोरी लीक डिटेक्शन
हीप बफर ओवरफ्लो हस्ताक्षर किए गए पूर्णांक ओवरफ्लो
स्टैक बफर ओवरफ्लो टाइपकास्ट ओवरफ्लो
प्रारंभिक आदेश कीड़े शून्य त्रुटियों से विभाजित करें
स्म्रति से रिसाव
सीमा से बाहर पहुंच

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

अमेरिकन फजी लोप (AFL) का उपयोग करना

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

फ़ज़िंग प्रक्रिया में मुख्य रूप से निम्नलिखित कार्य शामिल हैं:

AFL के साथ Fuzzing libEMF (ECMA-234 Metafile Library)

LibEMF (एनहांस्ड मेटाफाइल लाइब्रेरी) एक EMF पार्सिंग लाइब्रेरी है जो C / C ++ में लिखी गई है और ECMA-234 पर आधारित एक ड्राइंग टूलकिट प्रदान करती है। इस लाइब्रेरी का उद्देश्य वेक्टर ग्राफिक फाइलें बनाना है। इस पुस्तकालय का दस्तावेज़ीकरण यहां उपलब्ध है और इसे डेवलपर द्वारा बनाए रखा गया है।

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

स्रोत का संकलन

AFL के कोड इंस्ट्रूमेंटेशन क्षमताओं का उपयोग करने के लिए, हमें AFL कम्पाइलर आवरण के साथ स्रोत कोड को संकलित करना चाहिए afl-gcc / afl-g ++ और, एक अतिरिक्त पते के साथ सैनिटाइज़र ध्वज सक्षम होना चाहिए, निम्न कमांड का उपयोग करें:

./configure CXX = afl-g ++ CFLAGS = “- fsanitize = address -ggdb” CXXFLAGS = “- fsanitize = पता -ggdb” LDFLAGS = “- fsanitize = पता”

नीचे संकलन प्रक्रिया का एक स्नैपशॉट दिखाया गया है कि इंस्ट्रूमेंटेशन को कोड में कैसे जोड़ा जाता है:

Pwntools python पैकेज एक अच्छी उपयोगिता स्क्रिप्ट के साथ आता है, checksec, जो बाइनरी सुरक्षा गुणों की जांच कर सकता है। पुस्तकालय पर चेकिंग चेकिंग की पुष्टि करता है कि कोड अब आसन है। यह हमें गैर-क्रैश मेमोरी एक्सेस बग्स की खोज करने की अनुमति देगा:

टेस्ट हार्नेस एक प्रोग्राम है जो कमांड लाइन तर्क के रूप में प्रोग्राम को दी गई फ़ाइल को पार्स करने के लिए लाइब्रेरी से एपीआई का उपयोग करेगा। एएफएल इस दोहन का उपयोग इस कार्यक्रम के तर्क के रूप में अपनी उत्परिवर्तित फाइलों को पारित करने के लिए करेगा, जिसके परिणामस्वरूप प्रति सेकंड कई निष्पादन होंगे। हार्नेस लिखते समय, अत्यधिक उपयोग से बचने के लिए लौटने से पहले संसाधनों को जारी करना बेहद महत्वपूर्ण है जो अंततः सिस्टम को क्रैश कर सकता है। LibEMF लाइब्रेरी से API का उपयोग करके EMF फ़ाइलों को पार्स करने के लिए हमारा हार्नेस यहाँ दिखाया गया है:

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

afl-g ++ -o playemffile playemffile.c -g -O2 -D_FORTIFY_SOURCE = 0 -fsanitize = पता -I / usr / स्थानीय / शामिल / libEMF / -LL / usr / स्थानीय / lib /FEM -FEM

टेस्ट मामलों का संग्रह

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

फजर चला रहा है

फजर चलाना सिर्फ दौड़ना है AFL-फ़ज़्ज़ नीचे दिखाए अनुसार मापदंडों के साथ कमांड। हमें EMF फ़ाइलों (-i EMFs /), आउटपुट निर्देशिका (-o आउटपुट /) और @ के साथ हार्नेस बाइनरी के लिए मार्ग के इनपुट कॉर्पस प्रदान करने की आवश्यकता होगी, जिसका अर्थ है कि फेजर बाइनरी के लिए एक तर्क के रूप में फाइल पास करेगा । हमें भी उपयोग करने की आवश्यकता है -मैं कोई नहीं चूंकि ASAN लिखी गई बाइनरी को बड़ी मात्रा में मेमोरी की आवश्यकता होती है।

afl-fuzz -m कोई नहीं -i EMFs / -o आउटपुट / – /home/targets/libemf-1.0.11/tests/playemffile @@

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

इस लाइब्रेरी को भरने के लगभग 3 दिनों के बाद, हमारे पास 200 से अधिक अद्वितीय क्रैश थे, और जब हमने उन्हें ट्राइ किया तो हमने 5 अद्वितीय क्रैश को देखा। हमने MITER के साथ लाइब्रेरी के डेवलपर को इन क्रैश की सूचना दी, और स्वीकार किए जाने के बाद, CVE-2020-11863, CVE-2020-11864, CVE-2020-11865, CVE-2020-11866 और CVE-2020-13999 को असाइन किया गया इन कमजोरियों के लिए। नीचे हम इन कमजोरियों में से कुछ के लिए अपने निष्कर्षों पर चर्चा करते हैं।

CVE-2020-11865 – ईएमएफ स्टॉक ऑब्जेक्ट की गणना करते हुए सीमा मेमोरी एक्सेस से बाहर

फ़्यूज़र द्वारा निर्मित क्रैश में से एक को ट्राइज़ करते हुए, हमने एक इनपुट के रूप में दी गई EMF फ़ाइलों में से एक के लिए SIGSEGV (मेमोरी एक्सेस उल्लंघन) देखा। जब बाइनरी को सक्षम डिबगिंग प्रतीकों के साथ संकलित किया जाता है, तो ASAN प्रतीकात्मक स्टैक निशान का उत्पादन करने के लिए LLVM सिम्बोलाइज़र का उपयोग करता है। जैसा कि नीचे दिखाया गया है, आसन स्टैक ट्रेस को आउटपुट करता है जो आगे इस दुर्घटना में खुदाई करने में मदद करता है।

Disassembly में क्रैश बिंदु को देखने से स्पष्ट रूप से GLOBALOBJECTS :: खोज कार्य में सीमा मेमोरी एक्सेस का पता चलता है।

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

नीचे दिखाया गया कमजोर और निश्चित कोड है जहां वेक्टर आकार की जांच को जोड़ा गया था:

CVE-2020-13999 – EMR_SCALEVIEWPORTEX रिकॉर्ड करते समय पूर्णांक अतिप्रवाह

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

AFL की बाइनरी म्यूटेशन रणनीति के हिस्से के रूप में, यह एक नियतात्मक दृष्टिकोण लागू करता है जहां पूर्णांक के कुछ हार्डकोड सेट मौजूदा डेटा को प्रतिस्थापित करते हैं। इनमें से कुछ MAX_INT, MAX_INT-1, MIN_INT, इत्यादि हैं, जो किनारे की स्थितियों को ट्रिगर करने की संभावना को बढ़ाते हैं, जबकि अनुप्रयोग द्विआधारी डेटा को संसाधित करता है। एएफएल द्वारा ईएमएफ रिकॉर्ड संरचना में किया गया ऐसा एक उत्परिवर्तन नीचे दिखाया गया है:

इसके परिणामस्वरूप डिवीजन ऑपरेशन करते समय निम्नलिखित दुर्घटना हुई।

नीचे हम देखते हैं कि यह स्थिति, अंततः एक इनकार-सेवा के लिए अग्रणी है, कोड में विभाजन अतिप्रवाह चेक को जोड़कर तय किया गया था:

CVE-2020-11864 – मेमरी लीक्स जबकि प्रोसेसिंग मल्टीपल मेटाफिल रिकॉर्ड

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

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

इसके अतिरिक्त, हमने कई उपयोग-बाद की निःशुल्क स्थितियों और इनकार-संबंधी-सेवा के मुद्दों की भी रिपोर्ट की, जो अंततः यहां पुस्तकालय के नए संस्करण में तय किए गए थे।

निष्कर्ष

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