grimch/log4j-cve-2021-44228-workaroundlog4j CVE-2021-44228 भेद्यता के लिए सामान्य प्रयोजन वर्कअराउंड
यह परियोजना log4j CVE-2021-44228 भेद्यता के लिए एक सामान्य-उद्देश्यीय वर्कअराउंड प्रदान करती है, जिसका उपयोग तब किया जा सकता है जब आपके पास अल्पावधि में अपनी संबंधित परियोजना को पुनर्निर्मित करने या log4j-core जार को पैच करने का विकल्प न हो।
इसके पीछे का विचार काफी सरल है: हम क्लास लोडर को java रनटाइम विकल्प "-Xbootclasspath/a" का उपयोग करके "JndiLookup" क्लास का एक "खाली" संस्करण लोड करने के लिए बाध्य करते हैं।
इसलिए संपूर्ण वर्कअराउंड केवल इस एकल क्लास "org.apache.logging.log4j.core.lookup.JndiLookup.java" से मिलकर बना है और इसकी कोई अन्य निर्भरता नहीं है।
सुविधा के लिए एक pom.xml भी है, ताकि आप इसे Maven के माध्यम से संकलित कर सकें और jar बना सकें, लेकिन आप अपने पसंदीदा JDK का उपयोग करके "javac" और "jar" कमांड से भी यह आसानी से कर सकते हैं।
ध्यान दें कि "JndiLookup" क्लास का यह खाली संस्करण मूल log4j2 कार्यान्वयन के साथ संगत नहीं हो सकता, क्योंकि यह कुछ क्लास लोडिंग स्थितियों में विफल हो जाएगा।
वर्कअराउंड लागू करते समय आपको निम्नलिखित संदेश दिखाई देगा:
"WARN JNDI lookup class is not available because this JRE does not support JNDI.
JNDI string lookups will not be available, continuing configuration.
Ignoring java.lang.ClassCastException: class org.apache.logging.log4j.core.lookup.JndiLookup"
फिर भी Log4j2 बिना किसी समस्या के काम करता रहेगा, बस बिना किसी JNDI लुकअप के - बस इस तरह - JNDI लुकअप अक्षम कर दिया गया है!
एक बार जब आप क्लास संकलित कर लेते हैं और jar फ़ाइल बना लेते हैं, तो अपने Java कमांड की शुरुआत में "-Xbootclasspath/a:" विकल्प जोड़ें और उस निर्देशिका की ओर इंगित करें जहाँ आपने jar फ़ाइल रखी है (जैसे log4j-workaround-1.0-SNAPSHOT.jar)। इसे करने के उदाहरण के लिए proof of concept अनुभाग देखें।
आप इस वर्कअराउंड को जिस Java कमांड पर लागू करेंगे, वह कुछ भी प्रारंभ कर सकता है (Weblgic, Tomcat, spring द्वारा निर्मित fat jar, ...)।
यदि आप केवल वर्कअराउंड में रुचि रखते हैं, न कि यह जाँचने में कि यह वास्तव में काम करता है, तो आप निम्नलिखित को अनदेखा कर सकते हैं।
दृष्टिकोण को मान्य करने के लिए मैंने एक "POC" फ़ोल्डर जोड़ा है, जिसमें एक और Maven प्रोजेक्ट है। मैं कोई यूनिट परीक्षण उपयोग नहीं करना चाहता था, बल्कि प्रोडक्शन सेट-अप के करीब रहना चाहता था, जो फैट जार को स्पष्ट रूप से कमांड लाइन पर लॉन्च करते हैं या कंटेनर लॉन्च करते हैं, जैसे उस Tomcat के साथ जिसके साथ मैंने इसे मान्य किया है।
प्रूफ ऑफ कॉन्सेप्ट में दो क्लास हैं: "POC.java", जो कमांड लाइन पर वर्कअराउंड का परीक्षण करता है, और "POCServlet.java", जो एप्लिकेशन सर्वर में इसका परीक्षण करता है।
दोनों परिदृश्यों में "${jndi:ldap://localhost/test}" लॉग करने का प्रयास किया जाता है, जिसके कारण वर्कअराउंड लागू न होने पर log4j आपके लोकल होस्ट पर ldap से कनेक्ट करने का प्रयास करेगा और connection refused के साथ विफल हो जाएगा..
कमांड लाइन POC चलाने के लिए (एक बार जब आप इसे Maven में बना लें):
"target\log4j-workaround-1.0-SNAPSHOT\WEB-INF" निर्देशिका में जाएँ और वहाँ चलाएँ (यदि आप Windows कमांड लाइन पर हैं):
java -Xbootclasspath/a:..\..\..\..\target\log4j-workaround-1.0-SNAPSHOT.jar -classpath classes;lib\* com.github.grimch.log4j_workaround.poc.POC
POC को Tomcat के साथ चलाने के लिए:
"-Xbootclasspath" का उपयोग आखिर क्यों करें और वर्कअराउंड jar को "सामान्य" classpath की पहली प्रविष्टि के रूप में क्यों न रखें? खैर - कुछ कंटेनर आपको क्लासलोडिंग को इस प्रकार प्रभावित करने देते हैं कि परिनियोजित एप्लिकेशन आर्काइव में मौजूद jar फ़ाइलों को सिस्टम classpath में मौजूद समान jar फ़ाइलों पर वरीयता मिलती है। दूसरी ओर, बूटस्ट्रैप classpath में जो कुछ भी है, उसे बाकी सब पर वरीयता प्राप्त होती है।
हालाँकि, यदि आप निश्चित हैं कि आप इनमें से किसी भी चीज़ का उपयोग नहीं कर रहे हैं (जैसे Weblogic में "prefer-application-packages"), तो आप "-classpath" विकल्प का भी उपयोग कर सकते हैं।