Log4j मधील आणखी एक भेद्यता 2. Log4j मधील समस्या 8% Maven पॅकेजेस प्रभावित करतात

Log4j 2 लायब्ररी (CVE-2021-45105) मध्ये आणखी एक भेद्यता ओळखली गेली आहे, जी मागील दोन समस्यांप्रमाणेच धोकादायक म्हणून वर्गीकृत आहे, परंतु गंभीर नाही. नवीन समस्या तुम्हाला सेवा नाकारण्याची परवानगी देते आणि विशिष्ट ओळींवर प्रक्रिया करताना लूप आणि क्रॅशच्या स्वरूपात प्रकट होते. काही तासांपूर्वी रिलीज झालेल्या Log4j 2.17 मध्ये असुरक्षा निश्चित करण्यात आली होती. असुरक्षिततेचा धोका या वस्तुस्थितीमुळे कमी केला जातो की समस्या फक्त Java 8 असलेल्या सिस्टमवर दिसून येते.

लॉग आउटपुट स्वरूप निर्धारित करण्यासाठी ${ctx:var} सारख्या संदर्भित क्वेरी (संदर्भ लुकअप) वापरणार्‍या प्रणालींवर असुरक्षा प्रभाव पाडते. 4-अल्फा2.0 ते 1 पर्यंतच्या Log2.16.0j आवृत्त्यांमध्ये अनियंत्रित पुनरावृत्तीपासून संरक्षणाचा अभाव आहे, ज्यामुळे आक्रमणकर्त्याला लूप बनवण्यासाठी प्रतिस्थापनामध्ये वापरलेल्या मूल्यामध्ये फेरफार करण्याची परवानगी दिली, ज्यामुळे स्टॅक स्पेस संपुष्टात आली आणि क्रॅश झाला. विशेषतः, "${${::-${::-$${::-j}}}}" सारखी मूल्ये बदलताना समस्या आली.

याव्यतिरिक्त, हे लक्षात घेतले जाऊ शकते की ब्लूमिराच्या संशोधकांनी असुरक्षित Java ऍप्लिकेशन्सवर हल्ला करण्याचा पर्याय प्रस्तावित केला आहे जे बाह्य नेटवर्क विनंत्या स्वीकारत नाहीत; उदाहरणार्थ, डेव्हलपर किंवा Java ऍप्लिकेशन्सच्या वापरकर्त्यांच्या सिस्टमवर अशा प्रकारे हल्ला केला जाऊ शकतो. पद्धतीचा सार असा आहे की जर वापरकर्त्याच्या सिस्टमवर असुरक्षित Java प्रक्रिया असतील ज्या फक्त स्थानिक होस्टकडून नेटवर्क कनेक्शन स्वीकारतात किंवा RMI विनंत्यांवर प्रक्रिया करतात (रिमोट मेथड इनव्होकेशन, पोर्ट 1099), हल्ला JavaScript कोड अंमलात आणून केला जाऊ शकतो. जेव्हा वापरकर्ते त्यांच्या ब्राउझरमध्ये दुर्भावनापूर्ण पृष्ठ उघडतात. अशा हल्ल्यादरम्यान जावा ऍप्लिकेशनच्या नेटवर्क पोर्टशी कनेक्शन स्थापित करण्यासाठी, WebSocket API वापरला जातो, ज्यासाठी HTTP विनंत्यांप्रमाणेच, समान-उत्पत्तीचे निर्बंध लागू केले जात नाहीत (वेबसॉकेटचा वापर स्थानिक नेटवर्कवरील नेटवर्क पोर्ट स्कॅन करण्यासाठी देखील केला जाऊ शकतो. उपलब्ध नेटवर्क हँडलर निर्धारित करण्यासाठी होस्ट).

Log4j अवलंबनांशी संबंधित लायब्ररींच्या भेद्यतेचे मूल्यांकन करण्यासाठी Google द्वारे प्रकाशित केलेले परिणाम देखील स्वारस्यपूर्ण आहेत. Google च्या मते, समस्या मावेन सेंट्रल रेपॉजिटरीमधील सर्व पॅकेजपैकी 8% प्रभावित करते. विशेषतः, प्रत्यक्ष आणि अप्रत्यक्ष अवलंबनांद्वारे Log35863j शी संबंधित 4 Java पॅकेजेस असुरक्षिततेच्या संपर्कात आली होती. त्याच वेळी, Log4j केवळ 17% प्रकरणांमध्ये थेट प्रथम-स्तरीय अवलंबित्व म्हणून वापरला जातो आणि 83% प्रभावित पॅकेजेसमध्ये, बंधन Log4j वर अवलंबून असलेल्या इंटरमीडिएट पॅकेजद्वारे चालते, म्हणजे. द्वितीय आणि उच्च पातळीचे व्यसन (21% - द्वितीय स्तर, 12% - तृतीय, 14% - चौथा, 26% - पाचवा, 6% - सहावा). असुरक्षितता निश्चित करण्याच्या गतीने अद्याप बरेच काही हवे आहे; असुरक्षितता ओळखल्याच्या एका आठवड्यानंतर, 35863 ओळखल्या गेलेल्या पॅकेजेसपैकी, आतापर्यंत फक्त 4620 मध्ये समस्या निश्चित केली गेली आहे, म्हणजे. 13% वर.

दरम्यान, यूएस सायबरसिक्युरिटी आणि इन्फ्रास्ट्रक्चर प्रोटेक्शन एजन्सीने आणीबाणी निर्देश जारी केले ज्यात फेडरल एजन्सींना Log4j असुरक्षिततेमुळे प्रभावित झालेल्या माहिती प्रणाली ओळखणे आणि 23 डिसेंबरपर्यंत समस्या अवरोधित करणारे अद्यतने स्थापित करणे आवश्यक आहे. 28 डिसेंबरपर्यंत संस्थांनी त्यांच्या कामाचा अहवाल देणे आवश्यक आहे. समस्याप्रधान प्रणालींची ओळख सुलभ करण्यासाठी, असुरक्षा प्रदर्शित करण्यासाठी पुष्टी केलेल्या उत्पादनांची यादी तयार केली गेली आहे (यादीत 23 हजारांहून अधिक अनुप्रयोग समाविष्ट आहेत).

स्त्रोत: opennet.ru