In January 2022, Apache disclosed three vulnerabilities impacting Log4j 1.x versions.
Full disclosure: Log4j 1.x is an end-of-life product anyway, as of August 2015, and the recommended advice has always been to be on a safe log4j 2.x version. But, buried in these CVE disclosures is a critical Apache Chainsaw vulnerability that has been analyzed below.
To summarize quickly, the three CVEs disclosed this week are:
CVE-2022-23307
[Sonatype's CVSS rating: 9.8 / Critical]
- CVE-2022-23307: This remote code execution flaw is applicable to default instances, making it noteworthy. The vulnerability itself lurks in the Chainsaw component, which is included within Log4j 1.x versions.
Reported by a pseudonymous researcher @kingkk, CVE-2022-23307 is rather the same issue as CVE-2020-9493, with the newer identifier assigned specifically for Log4j.
Apache Chainsaw versions prior to 2.1.0 were vulnerable to untrusted deserialization, and therefore, the inclusion of this version in Log4j 1.x makes the latter vulnerable too. The remediation guidance for CVE-2020-9493 (also reported by kingkk) additionally states not to configure Chainsaw to read serialized log events but instead adopt a different receiver, such as XMLSocketReceiver.
CVE-2022-23305
[Sonatype's CVSS score: 9.8 / Critical]
- CVE-2022-23305: An SQL injection flaw in JDBC Appender is present in Log4j 1.x versions. This issue impacts versions specifically configured to use JDBCAppender, which means it's applicable to non-default configurations only.
The JDBCAppender in Log4j 1.2.x versions has been designed to accept SQL statements as configuration parameters such that the values to be inserted are converters from PatternLayout.
"The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged, allowing unintended SQL queries to be executed," states the advisory.
However, starting with Log4j v2.0-beta8, the JDBCAppender was re-introduced with support for parameterized SQL queries and other customizations over the columns to be written into logs.
Daniel Martin of NCC Group has been credited with reporting the issue.
CVE-2022-23302
[Sonatype's CVSS score: 7.2 / High]
- CVE-2022-23302: An untrusted deserialization flaw in Log4j 1.x due to JMSSink, applicable to non-default configurations only.
As reported by Google researchers Eduardo Vela, Maksim Shudrak, and Jacob Butler, the flaw is exploitable when the attacker has write access to the Log4j configuration or if the configuration references an attacker-controlled LDAP service.
"The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104," states Apache's advisory.
The Chainsaw RCE vulnerability
The term Chainsaw RCE vulnerability refers to a security flaw in software that allows an attacker to execute code (hence, "RCE" stands for "Remote Code Execution") on a computer or system. It's like giving a hacker the power to control your computer from afar.
On peeking inside one of the Log4j 1.x JARs using "tar -tvf," one can trivially spot the presence of Chainsaw classes:
On decompiling one of these classes, LoggingReceiver.class, the code responsible for untrusted deserialization surfaces within the run() method of its Slurper nested class:
Line 54 is where the Serializable interface's readObject() method is invoked without verifying the object type or restricting deserialization to only certain types of objects. As a result, an attacker who is able to send a malicious payload to the vulnerable Log4j 1.x version can trigger arbitrary code execution.
A vulnerability like this one can lead to data breaches, unauthorized access, and various other security problems. As such, you need to patch or fix these vulnerabilities as soon as they are discovered to protect your system from potential attacks.
Is logback impacted too?
With Log4j 1.x being impacted, a natural question that arises is if Logback is also impacted by these vulnerabilities. After all, Logback is a successor to Log4j, "picking up where log4j 1.x leaves off."
Firstly, there is no indication that Logback utilizes Apache Chainsaw.
Secondly, my sharp-eyed colleague Ankita Lamba, Senior Security Researcher, noticed that starting with logback 1.2.0, the project had implemented its own "hardened" object input stream to throw exceptions for invalid serialized objects it may parse.
The placement of these HardenedAccessEventInputStream objects in versions 1.2.0 and above, replacing the ObjectInputStream instances, largely mitigates the untrusted deserialization issue.
Thankfully, logback versions prior to 1.2.0 are known to be vulnerable to CVE-2017-5929.
Upgrade advice and staying safe
As mentioned above, Log4j 1.x versions have been end-of-life for quite some time now. As such, upgrading to the latest Log4j 2.x version is the recommended upgrade route.
Sonatype customers using next-generation Sonatype Intelligence-powered products, such as IQ, can rest easy as security data pursuant to CVE-2022-23302, CVE-2022-23305, and CVE-2022-23307 has been made available in our products with extensive detection capabilities (i.e. deep binary scanning) and dependable remediation guidance.
Additionally, CVEs and Sonatype-identified vulnerabilities applicable to all Log4j (1.x, 2.x) and 'logback' versions are available in IQ:
Finally, even if you aren't using any of Sonatype's products, Sonatype offers a free vulnerability scanner you can download or use online. The report will detail the usage of all vulnerable versions of Log4j in your repositories.
