News broke early Friday morning of a serious 0-day remote code execution (RCE) exploit in Log4j - CVE-2021-44228- the most popular Java logging framework used by Java software far and wide. This type of vulnerability is especially dangerous as it can be used to run any code via your software and requires very low skills to pull off from an attacker. Log4j is near ubiquitous in Java applications, so immediate action is needed from software maintainers to patch.
This affects anyone using Log4j to perform logging, and anyone using software that uses Log4j, which is a large population of enterprise Java software currently available.
A similar vulnerability was used in the famous Equifax hack with devastating results. What makes this issue potentially more dangerous is the wide adoption of log4j in most of the Java ecosystem.
We have released a dedicated Log4j updates page.
Please visit it for the latest statistics, updates, and resources for customers
- UPDATE 11.12 11:52UTC : Unlike mentioned in the video, it seems like JDK versions above 8 are affected. See below for up-to-date mitigation strategies. We have also updated the guidance for developers and operators.
- UPDATE 13.12 15:25 UTC: There is now strong evidence the JDK version does not matter and the only mitigation is to update log4j2 to 2.15.0. EDIT: This is now outdated
- UPDATE 14.12 12:06 UTC: There is evidence Log4j 1.x in certain circumstances can become vulnerable to another issue, CVE-2021-4104
- UPDATE 14.12 19:19 UTC: A new Log4j version, 2.16.0, was released. It is now the recommended remediation - see details below.
- UPDATE 17.12 14:36 UTC: A CVE has been discovered in Log4j 2.15.0 - CVE-2021-45046. All remediation activity should focus on updating log4j to 2.16.0
- UPDATE 17.12 22:00 UTC: We have released a dedicated Log4j resource center for customers & new Log4J 2.17.0 released
Early Friday morning GMT, a vulnerability Proof of Concept was published in a GitHub repository and made public.
It affects Apache Log4j between versions 2.0 and 2.14.1 and cannot be mitigated by updating the underlying JDK version. See below for current mitigation advice.
Coordinated with this release, Apache published a fix to the issue.
This is a low skilled attack that is extremely simple to execute. It allows the attacker to run Arbitrary Code on any application that is vulnerable and use this capability to execute an attack. Compared to the famous 2017 Struts2 CVE that led to the Equifax vulnerability this issue is potentially more far reaching, as Log4j is a far more widely adopted component.
This vulnerability affects any application that uses Log4j for logging - which includes software such as Minecraft, where we've already seen evidence of the vulnerability being exploitable using the built-in chat functionality. It's widely adopted in the enterprise Java software ecosystem, meaning you’ll need to also update all affected applications.
As with historical RCE attacks, within hours there is strong evidence this vulnerability is being mass scanned on the internet. This means immediate reactions are needed from all maintainers.
It only took less than 2 days for companies to be exploited with a similar vulnerability that occurred in 2017.
Sonatype has fast tracked the vulnerability and if you have scanned your software with Sonatype Lifecycle you'll receive automatic security alerts as a part of your usual continuous monitoring.
You can also run a manual search on Sonatype Lifecycle to check if you're affected. You can use the following REST API call to Sonatype IQ server to find the affected Log4j versions:
"http://localhost:8070/api/v2/search/component?stageId=release&componentIdentifier={"format":"maven","coordinates":{"groupId":"org.apache.logging.log4j","artifactId":"log4j-core","version":"*","extension":"*","classifier":"*"}}"
Additionally, the community has published a script that allows you to check if your application is vulnerable. We recommend you perform both a search and conduct a test ASAP.
If you aren't using any of Sonatype's products, Sonatype offers a free vulnerability scanner you can download or use online, and it will report usage of all vulnerable versions of Log4j in your repositories.
We have published guidelines on how you can find and fix Log4j with the Sonatype platform. Please see the following page:
The fixed version for this issue is out and was released by Apache - the main recommendation is to upgrade Log4j to the latest 2.17.0 version immediately. It is available via Maven Central. There is also a backported release 2.12.2 which is also now available via Central.
It's important to note, the initial fix 2.15.0 is secure against CVE-2021-44228. It does however contain another CVE that was discovered, CVE-2021-45046 that can cause remote code execution in certain non-default configurations.
Please see Apache Log4j's official security notes for up to date information.
You can also apply a Maven enforcer rule courtesy of Gunnar Morlin of Red Hat to prevent vulnerable packages from being included.
Apply patches to the software running Java as soon as they come out and plan to receive them as they are released over the coming days and hours. Expect there to be a large volume of urgent updates.
Other mitigation and monitoring strategies include the following:
There is also an application courtesy of Lari Hotari of Datastax that has a deliberately affected application you can use to test mitigations: https://github.com/lhotari/log4shell-mitigation-tester
Our software including Sonatype Lifecycle, Sonatype Repository Firewall, Sonatype Nexus Repository OSS and Sonatype Nexus Repository in versions 2.x and 3.x are NOT affected by CVE-2021-44228.
As the situation is ever evolving, we are keeping the above help article up to date relating to CVE-2021-44228.
We advise keeping your software upgraded at the latest version.