पिछले कुछ दिनों के दौरान शोधकर्ताओं के एक समूह द्वारा की गई कार्रवाई पर मामला मिनेसोटा विश्वविद्यालय से, क्योंकि कई के नजरिए से, लिनक्स कर्नेल में कमजोरियों की शुरूआत के संबंध में इस तरह के कार्यों का कोई औचित्य नहीं है।
और भले ही एक समूह मिनसोट शोधकर्ताओं का विश्वविद्यालयमाफी का एक खुला पत्र प्रकाशित करने के लिए, लिनक्स कर्नेल में परिवर्तन जिसकी स्वीकृति अवरुद्ध थी ग्रेग क्रोहा-हार्टमैन ने विवरण का खुलासा किया पैच के कर्नेल डेवलपर्स और इन पैच से जुड़े अनुचर के साथ पत्राचार के लिए प्रस्तुत किया।
यह उल्लेखनीय है कि सभी समस्या पैच को अस्वीकार कर दिया गया था अनुरक्षकों की पहल पर, किसी भी पैच को मंजूरी नहीं दी गई थी। यह तथ्य स्पष्ट करता है कि ग्रेग क्रोहा-हार्टमैन ने इतनी कठोर कार्रवाई क्यों की, क्योंकि यह स्पष्ट नहीं है कि यदि अनुचर द्वारा पैच को मंजूरी दी गई थी तो शोधकर्ताओं ने क्या किया होगा।
सिंहावलोकन करने पर, तर्क दिया कि वे बग रिपोर्ट करना चाहते थे और वे पैच को गिट में जाने की अनुमति नहीं देंगे, लेकिन यह स्पष्ट नहीं है कि वे वास्तव में क्या करेंगे या वे कितनी दूर जा सकते हैं।
कुल मिलाकर, अगस्त 2020 में, पांच पते गुमनाम पते acostag.ubuntu@gmail.com और jameslouisebond@gmail.com (जेम्स बॉन्ड से एक पत्र) से भेजे गए थे: दो सही और तीन छिपे हुए त्रुटियों सहित, उपस्थिति की उपस्थिति के लिए स्थितियां बना रहे थे। कमजोरियों।
प्रत्येक पैच में कोड की केवल 1 से 4 लाइनें होती थीं। खराब पैच के पीछे मुख्य विचार यह था कि मेमोरी लीक को ठीक करने से दोहरी मुक्त भेद्यता के लिए एक स्थिति बन सकती है।
परियोजना का उद्देश्य ओएसएस में पैचिंग प्रक्रिया की सुरक्षा में सुधार करना है। परियोजना के भाग के रूप में, हम ओएसएस पैचिंग प्रक्रिया के साथ संभावित समस्याओं का अध्ययन करते हैं, जिसमें समस्याओं और उन्हें संबोधित करने के लिए सुझाव भी शामिल हैं।
वास्तव में, इस अध्ययन से कुछ समस्याओं का पता चलता है, लेकिन इसका उद्देश्य सुधार के प्रयासों का आह्वान करना है
पैचिंग का परीक्षण और सत्यापन करने के लिए तकनीकों को विकसित करने के लिए और अधिक काम करने के लिए और अंत में ओएस को अधिक सुरक्षित बनाने के लिए और अधिक काम करने के लिए पैचिंग प्रक्रिया।इन पैच के आधार पर, हम उनके पैटर्न को सारांशित करते हैं, उन विशिष्ट कारणों का अध्ययन करते हैं जिनके कारण बग परिचय पैच को पकड़ना मुश्किल होता है (दोनों गुणात्मक और मात्रात्मक विश्लेषण के साथ), और सबसे महत्वपूर्ण समस्या को संबोधित करने के लिए सुझाव प्रदान करते हैं।
पहले समस्याग्रस्त पैच ने kfree () में कॉल जोड़कर मेमोरी रिसाव को ठीक किया किसी त्रुटि के मामले में नियंत्रण वापस करने से पहले, लेकिन इसके मुक्त होने के बाद मेमोरी क्षेत्र तक पहुंचने के लिए स्थितियां बनाना (उपयोग-बाद-मुक्त)।
निर्दिष्ट पैच अनुचर द्वारा खारिज कर दिया गया था, जिन्होंने समस्या की पहचान की और संकेत दिया कि एक साल पहले किसी ने पहले से ही एक समान परिवर्तन का प्रस्ताव करने की कोशिश की थी और इसे शुरू में स्वीकार कर लिया गया था, लेकिन भेद्यता की स्थिति की पहचान करने के बाद उसी दिन को त्याग दिया।
दूसरे पैच में भी रिलीज के बाद पहनने के मुद्दे की स्थिति थी। निर्दिष्ट पैच अनुचर द्वारा स्वीकार नहीं किया गया था, जिसने list_add_tail के साथ एक और समस्या के कारण पैच को अस्वीकार कर दिया था, लेकिन यह ध्यान नहीं दिया कि "chdev" पॉइंटर को put_device फ़ंक्शन में जारी किया जा सकता है, जिसे कॉल के लिए उपयोग किया जाता है dev_err (& चदेव -> देव ..)। हालांकि, पैच स्वीकार नहीं किया गया था, भेद्यता के लिए असंबंधित कारणों के लिए।
मजे की बात है, शुरू में यह माना गया था कि 4 में से 5 पैच में समस्याएं थीं, लेकिन शोधकर्ताओं ने खुद एक गलती की और एक समस्याग्रस्त पैच में, उनकी राय में, सही समाधान प्रस्तावित किया गया था, लॉन्च के बाद स्मृति का उपयोग करने की कथित शर्तों के बिना।
इस कार्य में, हम «अपरिपक्व भेद्यता» की अवधारणा प्रस्तुत करते हैं, जहां भेद्यता की स्थिति में कमी है, लेकिन यह एक वास्तविक स्थिति बन सकती है जब स्थिति निहित है
एक अन्य बग के लिए पैच द्वारा पेश किया गया।हम ऐसे उपकरण भी विकसित करते हैं जो हमें कोड के स्थानों को खोजने में मदद करते हैं जो पीड़ित हो सकते हैं
बग परिचय पैच और सुझाव है कि क्या इन बग परिचय पैच पता लगाने के लिए मुश्किल हो सकता है।एक सप्ताह बाद, स्मृति रिसाव के लिए तुच्छ सुधार की आड़ में कमजोरियों को बढ़ावा देने की संभावना पर चर्चा करने के प्रस्ताव के साथ कर्नेल डेवलपर्स को जानकारी भेजी गई थी, लेकिन दुर्भावनापूर्ण पैच प्रस्तुत करने के पिछले प्रयासों के बारे में कुछ नहीं कहा गया था।
तीसरे पैच को भी मेंटेनर द्वारा बिना किसी भेद्यता के बग के कारण खारिज कर दिया गया था (pdev में दोहरा आवेदन)।