तीन कर्नेल कमजोरियों की कहानी

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

तीन साल?

लेखन के समय, पूरी ट्रस्टवेव रिपोर्ट अभी तक उपलब्ध नहीं थी (अब इसे यहां डाउनलोड किया जा सकता है । - Approx। Per। ) । इसलिए, प्रस्तुत कथनों का विस्तृत अध्ययन संभव नहीं है। लेकिन ZDNet पर इस लेख को देखते हुए, औसत प्रतिक्रिया समय की गणना इन दो शून्य-दिन कमजोरियों से की गई थी:

• CVE-2009-4307 : ext4 फाइल सिस्टम कोड में शून्य त्रुटि द्वारा विभाजन। इस भेद्यता का फायदा उठाने के लिए, उपयोगकर्ता के लिए विशेष रूप से तैयार की गई छवि को ext4 फ़ाइल सिस्टम पर माउंट करना आवश्यक है।
• CVE-2009-4020 : HFS + फाइल सिस्टम में बफर ओवरफ्लो; लक्षित प्रणाली पर फ़ाइल सिस्टम की विशेष रूप से तैयार की गई छवि को बढ़ाकर, फिर से शोषण किया जाता है।

1 अक्टूबर 2009 को RN Sastry द्वारा ext4 फाइल सिस्टम से संबंधित एक समस्या बताई गई थी, जिन्होंने फाइल सिस्टम का एक परीक्षण (एक प्रकार का परीक्षण जिसमें त्रुटियों को यादृच्छिक इनपुट डेटा का उपयोग करके खोजा जाता है। - नोट प्रति ) किया। त्रुटि संदेश में एक फ़ाइल सिस्टम छवि शामिल थी जिसने बग को उकसाया, जो अनिवार्य रूप से इस भेद्यता के लिए एक "शोषण" है, जिसने ट्रस्टवेव को इसे शून्य-दिन भेद्यता कहने की अनुमति दी। और, चूंकि समस्या केवल कर्नेल ऑप्स (एक सिस्टम त्रुटि, जिसके बाद कर्नेल घबराहट अक्सर होती है) के कारण होती है, इसमें पीड़ित की ओर से भी सहयोग की आवश्यकता होती है (हमलावर द्वारा तैयार की गई फ़ाइल सिस्टम बढ़ते हुए), ext4 डेवलपर्स ने सब कुछ छोड़ने के लिए आवश्यक नहीं माना और भेद्यता को तुरंत ठीक करें। टेड त्सो ने नवंबर के अंत में सुधार शुरू किया। SUSE ने 17 जनवरी, 2010 को एक भेद्यता सुधार अद्यतन प्रकाशित करने के लिए पहली बार किया था। Red Hat ने मार्च के अंत तक अद्यतन जारी नहीं किया, भेद्यता के बारे में सूचना जारी होने के लगभग पाँच महीने बाद, और Mandriva ने फरवरी 2011 तक प्रतीक्षा की।

यह तर्क दिया जा सकता है कि सब कुछ जल्दी से नहीं हुआ था, यहां तक ​​कि एक बग के लिए बहुत कम प्राथमिकता के साथ, लेकिन ये "तीन साल" कहाँ से थे? वे दिखाई दिए क्योंकि x86 आर्किटेक्चर पर पैच ठीक से काम नहीं करता था। शी वांग ने कहा कि समस्या अभी भी मौजूद है, 26 दिसंबर, 2011 को, और 9 जनवरी, 2012 को एक व्याख्यात्मक सुधार भेजा गया। इस समस्या के लिए एक नया सीवीई नंबर ( सीवीई -2018-2100 ) सौंपा गया था, और इस फिक्स को जल्दी से मुख्य शाखा में डाला गया था। रखवाले विशेष रूप से चुस्त नहीं थे, हालांकि, डेबियन ने मार्च में अपडेट, मई में उबंटू और रेड हैट ने नवंबर के मध्य तक इंतजार किया। उपयोगकर्ताओं को फिक्स डिलीवर करने के लिए भेद्यता की खोज करने के बाद लगभग ग्यारह महीने लग गए। जिस समय से रेड हैट अपडेट तक समस्या का पता चला था जिसने आखिरकार समस्या का समाधान किया, वास्तव में, तीन साल से अधिक समय बीत चुके हैं।

HFS / HFS + के साथ कहानी बहुत समान है। एचएफएस में बफर ओवरफ्लो समस्या को हल करने के लिए पहला पैच दिसंबर 2009 की शुरुआत में अमेरिगो वांग द्वारा प्रकाशित किया गया था। फिक्स को 15 दिसंबर को लिनुस द्वारा नियंत्रित किया गया था, और रेड हैट मेंटेनर्स ने 19 जनवरी 2010 को अपडेट वितरित करना शुरू किया। कुछ अनुरक्षक भी धीमे थे, लेकिन इस भेद्यता को शोषण करना भी मुश्किल माना जाता था और इसे कम प्राथमिकता माना जाता था।

समस्या यह है कि कर्नेल HFS + नामक एक और (अधिक हालिया) फ़ाइल सिस्टम का समर्थन करता है। यह एक अलग कार्यान्वयन है, जिसमें मूल HFS कार्यान्वयन से कॉपी किए गए कोड की एक उचित मात्रा होती है, जैसे ext4 की शुरुआत ext3 प्रतिलिपि के साथ की गई थी। इस तरह के कोड डुप्लीकेशन का खतरा सर्वविदित है: डेवलपर एक कॉपी में समस्या को ठीक करता है, यहां तक ​​कि यह संदेह किए बिना कि एक ही समस्या दूसरे में हो सकती है। स्वाभाविक रूप से, यह यहां हुआ। एचएफएस + के कार्यान्वयन में एक ही बफर अतिप्रवाह भेद्यता थी, लेकिन अप्रैल 2012 के अंत में टिमो वार्न ने कई कर्नेल डेवलपर्स का ध्यान आकर्षित होने तक इसके बारे में किसी ने भी नहीं सोचा था। ग्रेग क्रोहा-हार्टमैन ने 4 मई को परिवर्तन पोस्ट किए , और कुछ दिनों बाद यह मुद्दा सार्वजनिक हो गया। और फिर से, एक नया CVE नंबर ( CVE-2012-2319 ) सौंपा गया , और फिर से अनुरक्षकों को सुधार के साथ खराब कर दिया। OpenSUSE ने जून में अपडेट जारी किया, जबकि Red Hat ने अक्टूबर तक इंतजार किया, इस मुद्दे को ज्ञात हुए पांच महीने बीत चुके हैं। रेड हैट में पैच जारी करने की खोज को तीन साल से कम समय बीत चुका है।

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

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

इस बीच, 2013 में

संभवतः ऊपर दिखाया गया सुस्ती कमजोरियों के लिए एक स्वाभाविक प्रतिक्रिया है जो वास्तव में किसी को परेशान नहीं करता है। यदि वे अधिक गंभीर प्रतिक्रिया थे, तो निस्संदेह यह बेहतर होगा। और जैसा कि आमतौर पर होता है, लेख लिखने के समय (लेख 19 फरवरी, 2013 को प्रकाशित हुआ था। - परिशिष्ट। प्रति। ), एक खुली भेद्यता है, ताकि हम देख सकें कि हम कितनी अच्छी तरह से पुनरावृत्ति कर सकते हैं। और जवाब उत्साहजनक नहीं है।

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

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

मेरे पास यह सब देखने के लिए समय नहीं है, लेकिन पहली नज़र में, यह कई वर्षों में सबसे खराब भेद्यता है। वितरण कर्नेल के रखरखाव के लिए (मुख्य शाखा के अलावा, जो लगभग एक महीने पहले पैच किया गया था), यह 0-दिन है।

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

रेड हैट ओलेग नेस्टरोव के हिट्स ने जनवरी में मुख्य शाखा को वापस मारा। रेड हैट में समस्या क्यों नहीं थी (?) सभी गंभीरता से, अच्छी तरह से, या अंत में यह जानकारी प्रकाशित नहीं की गई थी कि इस समय उनकी कौन सी गुठली इस भेद्यता की चपेट में है।

यह कथन बताता है कि भविष्य में इसी तरह की समस्याएं संभव हैं। इस बीच, दुनिया भर के उपयोगकर्ताओं और सिस्टम प्रशासकों को इस बारे में चिंता करने की आवश्यकता है कि क्या उनके सिस्टम कमजोर हैं, और कौन इन कमजोरियों का फायदा उठा सकता है।

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

अनुवादक से नोट:
डेबियन पैच 26 फरवरी को रेड हैट पर, 26 फरवरी को उबंटू में, 21 फरवरी को उबंटू में, 25 फरवरी को ओपनसस में जारी किया गया था।