काही दिवसांपूर्वी ही बातमी प्रसिद्ध झाली होती सी मानक लायब्ररी uClibc आणि uClibc-ng मध्ये, अनेक एम्बेडेड आणि पोर्टेबल उपकरणांमध्ये वापरले जाते, एक असुरक्षा ओळखली गेली आहे (अद्याप नियुक्त केलेले नाही CVE सह), जे DNS कॅशेमध्ये डमी डेटा बदलण्याची परवानगी देते, ज्याचा वापर कॅशेमधील अनियंत्रित डोमेनचा IP पत्ता स्पूफ करण्यासाठी आणि आक्रमणकर्त्याच्या सर्व्हरवर डोमेनच्या विनंत्या पुनर्निर्देशित करण्यासाठी केला जाऊ शकतो.
या समस्येबाबत नमूद करण्यात आले आहे की राउटर, ऍक्सेस पॉइंट्स आणि IoT उपकरणांसाठी विविध Linux फर्मवेअर प्रभावित करते, तसेच OpenWRT आणि एम्बेडेड जेंटू सारखे एम्बेडेड लिनक्स वितरण.
असुरक्षा बद्दल
असुरक्षितता क्वेरी पाठवण्यासाठी कोडमध्ये अंदाज लावता येण्याजोग्या व्यवहार अभिज्ञापकांच्या वापरामुळे आहे DNS चे. DNS क्वेरी आयडी पोर्ट क्रमांकांचे आणखी यादृच्छिकीकरण न करता फक्त काउंटर वाढवून निवडले होते, जे DNS कॅशेला विष देणे शक्य केले बोगस प्रतिसादांसह UDP पॅकेट्स पूर्वपूर्वपणे पाठवून (प्रतिसाद वास्तविक सर्व्हरकडून प्रतिसादापूर्वी आल्यास आणि योग्य ओळख समाविष्ट असल्यास स्वीकारला जाईल).
2008 मध्ये प्रस्तावित केलेल्या कामिंस्की पद्धतीच्या विपरीत, व्यवहार आयडीचा अंदाज लावणे देखील आवश्यक नाही, कारण ते सुरुवातीला अंदाज करण्यायोग्य आहे (सुरुवातीला, ते 1 वर सेट केले आहे, जे प्रत्येक विनंतीनुसार वाढते आणि यादृच्छिकपणे निवडलेले नाही).
स्वतःचे रक्षण करण्यासाठी आयडी अंदाज विरुद्ध, तपशील पुढे नेटवर्क पोर्ट क्रमांकांच्या यादृच्छिक वितरणाचा वापर करण्याची शिफारस करते मूळचे जेथून DNS क्वेरी पाठवल्या जातात, जे ID च्या अपुर्‍या आकाराची भरपाई करते.
जेव्हा पोर्ट यादृच्छिकीकरण सक्षम केले जाते, तेव्हा डमी प्रतिसाद तयार करण्यासाठी, 16-बिट अभिज्ञापक निवडण्याव्यतिरिक्त, नेटवर्क पोर्ट क्रमांक निवडणे देखील आवश्यक आहे. uClibc आणि uClibc-ng मध्ये, असे यादृच्छिकीकरण स्पष्टपणे सक्षम केलेले नव्हते (जेव्हा बाइंड कॉल केले होते, तेव्हा एक यादृच्छिक स्रोत UDP पोर्ट निर्दिष्ट केलेला नव्हता) आणि त्याची अंमलबजावणी ऑपरेटिंग सिस्टम कॉन्फिगरेशनवर अवलंबून होती.
जेव्हा पोर्ट यादृच्छिकीकरण अक्षम केले जाते, कोणता रिक्वेस्ट आयडी वाढवायचा हे ठरवणे हे क्षुल्लक काम म्हणून चिन्हांकित केले आहे. परंतु यादृच्छिकतेच्या बाबतीतही, आक्रमणकर्त्याला फक्त 32768-60999 श्रेणीतील नेटवर्क पोर्टचा अंदाज लावणे आवश्यक आहे, ज्यासाठी तो वेगवेगळ्या नेटवर्क पोर्टवर एकाचवेळी मोठ्या प्रमाणात डमी प्रतिसाद पाठवू शकतो.
समस्या uClibc आणि uClibc-ng च्या सर्व वर्तमान आवृत्त्यांमध्ये पुष्टी केली गेली आहे, uClibc 0.9.33.2 आणि uClibc-ng 1.0.40 च्या नवीनतम आवृत्त्यांसह.
"हे लक्षात घेणे महत्वाचे आहे की मानक C लायब्ररीवर परिणाम करणारी असुरक्षा खूपच जटिल असू शकते," टीमने या आठवड्यात ब्लॉग पोस्टमध्ये लिहिले.
"एकाच प्रोग्राममधील अनेक पॉइंट्सवर असुरक्षित फंक्शनला शेकडो किंवा हजारो कॉल्स असतीलच असे नाही, तर असुरक्षा त्या लायब्ररीचा वापर करण्यासाठी कॉन्फिगर केलेल्या इतर बहु-विक्रेता प्रोग्राम्सच्या अनिश्चित संख्येवर परिणाम करेल."
सप्टेंबर 2021 मध्ये, असुरक्षिततेची माहिती पाठवण्यात आली समन्वित अॅरे तयार करण्यासाठी CERT/CC ला. जानेवारी २०२२ मध्ये, 200 पेक्षा जास्त उत्पादकांसह समस्या सामायिक केली गेली CERT/CC शी संबंधित.
मार्चमध्ये, uClibc-ng प्रकल्पाच्या देखभाल करणार्‍याशी स्वतंत्रपणे संपर्क साधण्याचा प्रयत्न केला गेला, परंतु त्यांनी उत्तर दिले की ते स्वत: असुरक्षिततेचे निराकरण करू शकत नाहीत आणि निराकरण करण्यासाठी मदत मिळण्याच्या आशेने समस्येबद्दल माहिती सार्वजनिकपणे उघड करण्याची शिफारस केली. समुदाय निर्मात्यांकडून, NETGEAR ने असुरक्षा काढून टाकून अपडेट जारी करण्याची घोषणा केली.
हे लक्षात घेणे महत्त्वाचे आहे की मानक C लायब्ररीवर परिणाम करणारी असुरक्षा खूपच गुंतागुंतीची असू शकते. एकाच प्रोग्राममधील एकाधिक पॉइंट्सवर असुरक्षित फंक्शनसाठी शेकडो किंवा हजारो कॉल्स असतीलच, परंतु असुरक्षा त्या लायब्ररीचा वापर करण्यासाठी कॉन्फिगर केलेल्या एकाधिक विक्रेत्यांकडील इतर प्रोग्राम्सच्या अनिश्चित संख्येवर परिणाम करेल.
हे लक्षात घेतले आहे की असुरक्षा अनेक उत्पादकांच्या उपकरणांमध्ये प्रकट होते (उदाहरणार्थ, uClibc Linksys, Netgear आणि Axis मधील फर्मवेअरमध्ये वापरले जाते), परंतु असुरक्षितता uClibc आणि uClibc-ng मध्ये अनपॅच राहिल्यामुळे, डिव्हाइसेसबद्दल तपशीलवार माहिती आणि विशिष्ट ज्या उत्पादकांच्या उत्पादनांमध्ये समस्या आहे, ते उघड होईपर्यंत.
शेवटी आपल्याला त्याबद्दल अधिक जाणून घेण्यात स्वारस्य असल्यास, आपण तपशील तपासू शकता पुढील लिंकवर