January 25, 2022 | Security intelligence

Vulnerabilities in Log4j – continued

This is an update to our blog post on 21 December 2021 covering Log4j vulnerabilities. Since then, Apache Log4j2 has released version 2.17.1, three more vulnerabilities have been discovered in Log4j versions 1.x, and developers released ReLoad4j – a migration path for users of Log4j 1.x. As this is a constantly developing situation, we recommend regular monitoring of the latest reports, vendor updates, and actioning the recommendations provided.

Details

Log4j2

Apache released Log4j2 version 2.17.1 fixing another vulnerability, tracked as CVE-2021-44832, which was discovered in version 2.17.0. The issue in Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) is due to improper input validation. It was rated with medium severity and assigned with a CVSS score of 6.6. The exploit path appears to be complex because it requires a threat actor to meet several conditions for successful code execution. Some of the conditions require high privilege access to the target system and write permissions to a log configuration file.

Log4j1

On 18 January 2022, Apache disclosed three new vulnerabilities affecting Log4j versions 1.x, advising users to upgrade to Apache Log4j2. One of these flaws affects the Chainsaw component in Log4j 1.x. It was assigned a critical severity rating, and is tracked as CVE-2022-23307. Two other vulnerabilities were rated with high severity and are tracked as CVE-2022-23302 and CVE-2022-23305.

Log4j versions 1.x reached end-of-life (EoL) in 2015, and Apache is no longer releasing updates to fix flaws in these versions, leaving the systems running them vulnerable. Our 16 December blog covered some of the previously discovered vulnerabilities in this version.

Reload4j

Log4j 1.x has a configuration and an Application Programming Interface (API) that are different from other (supported) logger versions, such as Log4j2, Slf4j, and Logback. These differences cause compatibility issues and make the recommended update to supported versions difficult for some organizations.

As an EoL version, Log4j 1.x also no longer receives support, and its maintainers have started a separate project to fix the known security issues. In January 2022, the deprecated Log4j 1.2.x dependency was replaced by a fork of Apache Log4j version 1.2.17, Reload4j. It offers a migration path for users who have an urgent need to fix vulnerabilities in Log4j 1.x, without needing to make changes to source code. Reload4j is a temporary solution to mitigate urgent issues before a change to another logger can be made.

Third-party updates

We estimate that over 6000 products are affected by the Log4j group of vulnerabilities. Vendors who have recently released updates include Microsoft, Adobe, Cisco, SAP, IBM, Oracle, and VMWare. VMWare reported current exploitation attempts of its VMware Horizon servers.

Recommendations

If you are using Log4j2 versions older than 2.17.0, we recommend updating to the latest version as soon as possible. If you have already updated Log4j to version 2.17.0, we recommend updating to Log4j versions 2.17.1 for Java 8+, Log4j 2.3.2 for Java 6, or 2.12.4 for Java 7.

If you are still running versions Log4j 1.x, we recommend using Reload4j as a migration path and changing to a supported logger as a long-term solution.

We also recommend monitoring for third-party application updates and applying them when they become available. If a product you are using is not on the list, we recommend contacting your vendor to inquire about the security status of their application in relation to this set of vulnerabilities.

We recommend reviewing the list of mitigations provided by the vendors and applying them in the event that you are unable to apply the updates immediately. Please keep in mind that these measures only provide temporary and partial protection against this threat and should not be relied on as a replacement for a product update.