A Bug in the Ubiquitous Log4j Library Can Allow an Attacker to Execute Arbitrary Code on Any System That Uses Log4j to Write Logs. Does Yours
Yesterday the Apache Foundation released an emergency update for a critical zero-day vulnerability in Log4j, a ubiquitous logging tool included in almost every Java application. The issue has been named Log4Shell and received the identifier CVE-2021-44228.
The problem revolves around a bug in the Log4j library that can allow an attacker to execute arbitrary code on a system that is using Log4j to write out log messages. This security vulnerability has a broad impact and is something anyone with an application containing Log4j needs to immediately pay attention to.
Why addressing Log4Shell is a major challenge
Log4j is a library that is used by many Java applications. It’s one of the most pervasive Java libraries to date. Most Java applications log data, and there’s nothing that makes this easier than Log4j.
The challenge here is finding Log4j because of the way Java packaging works. It’s possible you have Log4j hiding somewhere in your application and don’t even know it.
In the Java ecosystem, dependencies are distributed as Java archive (JAR) files, which are packages that can be used as a Java library. Commonly used tools, such as Maven and Gradle, can automatically add JAR files as you build your Java application. It’s also possible for a JAR to contain another JAR to satisfy a dependency, which means a vulnerability can be hidden several levels down in your application. In some situations, one dependency pulls in hundreds of other dependencies making it even more difficult to find.
Essentially, in the Java world, you can have a JAR nested in a JAR nested in a JAR. This creates many layers that all need to be investigated. Just looking at the JARs your project pulls in directly may not be enough, since Log4j could be hiding inside of another JAR file!