शोषण केल्यास, या त्रुटी हल्लेखोरांना संवेदनशील माहितीवर अनधिकृत प्रवेश मिळवू शकतात किंवा सामान्यत: समस्या निर्माण करू शकतात
काही दिवसांपूर्वी बातमी आली होती एक असुरक्षितता आढळली (CVE-2023-4273 अंतर्गत आधीच सूचीबद्ध) exFAT फाइल प्रणालीसाठी ड्राइव्हरमध्ये लिनक्स कर्नल मध्ये पुरवले जाते.
समस्याविशेषतः डिझाइन केलेले विभाजन माउंट करताना कंट्रोलर परवानगी देतो या वस्तुस्थितीत खोटे आहे, (उदाहरणार्थ, दुर्भावनायुक्त USB फ्लॅश प्लग इन करून), स्टॅक ओव्हरफ्लो दाबा आणि कर्नल अधिकारांसह तुमचा कोड चालवा.
समस्या अशी आहे: कोड असे गृहीत धरतो की फाइलनाव इनपुट नेहमी 255 वर्णांमध्ये बसणारे संकलित फाइलनाव तयार करतात (मर्यादा 258 वर्ण आहे, नल बाइटसाठी 1 अतिरिक्त वर्ण आणि रूपांतरणासाठी 2 अतिरिक्त वर्ण समाविष्ट आहेत). निर्देशिका नोंदींच्या संचामध्ये फाईलनावच्या 255 पेक्षा जास्त वर्ण संचयित करणे हे फाइलसिस्टम स्वरूपाचे उल्लंघन आहे, परंतु ते लिनक्स ड्रायव्हरद्वारे स्वीकारले जाते, परंतु स्टॅक ओव्हरफ्लो देखील कारणीभूत ठरते (कारण फाइलनाव स्टॅकद्वारे वाटप केलेल्या व्हेरिएबलमध्ये जोडलेले आहे).
असुरक्षिततेबद्दल, असे नमूद केले आहे की, हे आणिआकार तपासणी अयशस्वी झाल्यामुळे s शोषण फाईलचे नाव स्टॅक-अलोकेटेड बफरमध्ये कॉपी केल्याने कर्नल स्टॅक ओव्हरफ्लो होतो जर खूप लांब फाइलनाव 255 वर्णांच्या फाइलसिस्टम मर्यादेपेक्षा जास्त असेल.
exfat_extract_uni_name() फंक्शन एकदा नल कॅरेक्टर (0x0000) समोर आल्यानंतर डेस्टिनेशन बफरमध्ये वर्ण कॉपी करणे थांबवते आणि कॉपी केलेल्या वर्णांची संख्या परत करते. परंतु कॉलर रिटर्न व्हॅल्यूकडे दुर्लक्ष करतो आणि पुढील पुनरावृत्तीसाठी पॉइंटर 15 वर्ण (30 बाइट्स) पुढे करतो. म्हणून, एका पुनरावृत्तीमध्ये 14 वर्ण किंवा 28 बाइट्स वगळणे (अखंड सोडणे) शक्य आहे.
असुरक्षितता दीर्घ नावाची पुनर्रचना करणाऱ्या फंक्शनमध्ये उपस्थित आहे डायरेक्ट्री इंडेक्समधून फाइल नावाच्या भागांसह रेकॉर्ड्स चक्रीयपणे वाचणे आणि परिणामी नावाचे भाग अंतिम लांब नावामध्ये विलीन करणे.
त्या फंक्शनसाठी कोडमधील आकार तपासणी नावाच्या भागासह प्रत्येक एंट्रीच्या सापेक्ष केली गेली, परंतु अंतिम नाव समाविष्ट केले नाही (उदाहरणार्थ, नाव 100 भागांमध्ये विभागले जाऊ शकते आणि बफरमधील 1500 वर्णांऐवजी 258 वर्णांपर्यंत पोहोचू शकते. ).
अन्वेषक ज्याने असुरक्षा शोधून काढली प्रोटोटाइप शोषण तयार करण्यास सक्षम होते जे तुम्हाला सिस्टमवर तुमचे विशेषाधिकार वाढविण्यास अनुमती देते. व्हर्च्युअलबॉक्स व्हर्च्युअल मशीनवर चाचणी केल्यावर, शोषण 100% वेळेत कार्य करते, परंतु जेव्हा हार्डवेअरच्या वर चालणाऱ्या सामान्य वातावरणात चालवले जाते तेव्हा ते ट्रिगर होण्याची शक्यता सुमारे 50% पर्यंत घसरते.
विशेषतः, माझे शोषण नल-टर्मिनेटेड स्ट्रिंगवर स्टॅक-अलोकेटेड पॉइंटर ओव्हरराइट करते, त्यामुळे या स्ट्रिंगमध्ये टर्मिनेटिंग नल कॅरेक्टर जोडण्याचा पुढील प्रयत्न प्रत्यक्षात "आक्रमकाने निवडलेल्या मेमरीच्या स्थानावर एक नल बाइट लिहा.
असेही नमूद केले आहे UEFI सुरक्षित बूट मोडमध्ये बूट केलेल्या कर्नलशी तडजोड करण्यासाठी भेद्यता वापरली जाऊ शकते, कारण त्यात उल्लेख आहे की असुरक्षित कर्नल असलेली प्रतिमा, संबंधित init स्क्रिप्टसह (आणि शोषण, अर्थातच), जी रिअल ऑपरेटिंग सिस्टमच्या आधी बूट होते, बूट करण्यायोग्य ड्राइव्हवर ठेवली जाते. बूट केल्यावर, ही प्रतिमा दुर्भावनापूर्ण (आणि स्वाक्षरी न केलेले) कर्नल मॉड्यूल लोड करते, जे कर्नल मोडवर त्याचे नियंत्रण स्थापित करते आणि नंतर वास्तविक ऑपरेटिंग सिस्टमवर स्विच करते (उदाहरणार्थ, केक्सेक कॉल वापरणे).
शेवटी हे लक्षात घेण्यासारखे आहे की समस्या अद्याप समर्थित असलेल्या लिनक्सच्या आवृत्त्यांमध्ये निश्चित केली गेली आहे. भेद्यता प्रकटीकरणाच्या वेळी, सर्वात वर्तमान लिनक्स कर्नल आवृत्ती लिनक्स आवृत्ती 6.4.10 होती, परंतु नवीन आवृत्ती 6.5 मध्ये आधीच निराकरण आहे.
विविध वितरणांमध्ये समाधानाचा मागोवा घेण्यात स्वारस्य असलेल्यांसाठी, ते खालील पृष्ठांवरून असे करू शकतात: डेबियन, उबंटू, रहेल, SUSE y फेडोरा.
आपण असाल तर याबद्दल अधिक जाणून घेण्यात स्वारस्य आहे, मध्ये तपशील तपासू शकता खालील दुवा.