Log4j CVE-2021-44228

Solutions

Think about if you actually really require Log4j2 Core. Most likely, your own code (or some 3rd-party library you depend on) only need Log4j's Logging API façade - but can log to another back-end. You could therefore simply completely exclude the org.apache.logging.log4j:log4j-core dependency.

Use one of several available "Logging API Bridges" to connect (only) log4j-api with another Logging Implementation back-end:

1. Log4j2-SLF4j-Logback using log4j-to-slf4j

2. Log4j2-to-JUL from LOG4J2-3282 by me, as https://github.com/vorburger/Learning-Log4j2 illustrates.

This makes particular sense if you, or your Cloud Provider, has existing infrastructure for the respective back-end:

• Google Cloud Logging Logback Appender, see on GitHub, also with Spring Framework integration

Background

• https://logging.apache.org/log4j/2.x/security.html
• https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Detection & Scanning, Attack Surface

• github/codeql#7354
• google/tsunami-security-scanner-plugins#219
• https://github.com/YfryTchsGD/Log4jAttackSurface (with Memes)

Mitigations

• apache/logging-log4j2#608
• https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot
• https://community.openhab.org/t/openhab-and-the-log4j-security-vulnerability/129901
• https://github.com/vorburger/MariaDB4j/issues/509

Exploit

• https://www.lunasec.io/docs/blog/log4j-zero-day/#exploit-steps