There is a new zero-day exploit of the famous
log4j security exploit, help you determine if you are compromised, how to fix the exploit, and crucially, how to ascertain that you have resolved the log4j security exploit.
Quick specifics about the log4j-core
- Log4J: The CVE-2021-44228 vulnerability affects only the
- Springboot: The bundle libraries
spring-boot-starter-loggingare not affected according to Spring. Unless of cause you have swapped them out to directly use
log4j-coreor another logging library that transitively brings it in scope.
- So far reports seems to suggest applications are only affected when user inputs are logged.
- PS: Springboot says,
v2.6.2releases (due Dec 23, 2021) will contain the fixed
Although the affected versions are anything between
beta versions of
2.15.* would be affected. The most secure/”permanent” fix is to update your log4j library to
2.15.0 immediately. Please see Maven Central and log4j security announcements or carry on reading.
Am I affected?
Anyone running Java is affected. With the assumption that you would have something at least in your application’s transitive dependencies that bring in log4j if you are not using it directly. Best to assume you have it and act accordingly. In practice, any java application that takes in a user input that may end up in a log is affected given that log4j is ubiquitous in the java community!
How to tell which version of Log4J library I have
You can use your dependencies managers like Maven or Gradle to print out all your dependencies and their versions to verify what version of Log4J you have.
For example, for Gradle:
# execute, logging out only the log4j dependency lines ./gradlew dependencies | grep “log4j”
Also, note you can right-click on your
build.gradle file in popular IDEs like IntelliJ then chose to “generate visual dependency graph” / “effective dependency”
How to fix the log4J zero-day secuirty exploit
Example fix of the Log4j zero day exploit for Maven
# Override the log4j dependency of a Springboot project <properties> <log4j2.version>2.15.0</log4j2.version> </properties> # And then verify the override works ./mvnw dependency:list | grep log4j
Example fix of the log4j zero day exploit for Gradle
# Via gradle's platform support add implementation(platform("org.apache.logging.log4j:log4j-bom:2.15.0")) # or for those with Springboot simply set the log4j's version ext['log4j2.version'] = '2.15.0' # And then verify the override works ./gradlew dependencyInsight --dependency log4j-core
Where upgrading the dependency is not possible
A workaround exists for some versions, such as releases >=2.10, by setting either the system property
log4j2.formatMsgNoLookups or any of the following:
# In the JVM.Options file, add this: ‐Dlog4j2.formatMsgNoLookups=True
# or set the environment variable:
# or simply run the application with (you may need to add quotes, depending on your shell . i.e "true") java -Dlog4j2.formatMsgNoLookups=true -jar myapplication.jar
Popular applications affected by the log4J critical vulnerability
If you think you are not affected, have a look at this flavour of applications that would be affected:
- Spring Boot
- Apple iCloud
Yes, that’s almost any good Java application out there…
As a final reminder, this vulnerability is classed as critical by Apache. Apache describes a Critical vulnerability as one “which a remote attacker could potentially exploit to get Log4j to execute arbitrary code (either as the user the server is running as or root). These are the sorts of vulnerabilities that could be exploited automatically by worms”. Here are additional resources for you on the recent Log4J security vulnerability: