TL;DR - The latest vulnerabilities found in Log4j
2.17.0 are much less serious than the hype would suggest.
Continue to patch your systems to at least Log4j
2.17.0 (Java 8) or
2.12.3 (Java 7).
Anyone on this train deserves a much-needed break.
After a DOS attack with limited impact was discovered
2.16.0 and log4j was updated to
2.17.0 to fix it, another
even less impactful vulnerability was discovered in
2.17.0. I wonder if we should say "vulnerability" in quotes because
this latest vulnerability requires an attacker to have access to the
logger configuration file, which is a very privileged and unlikely scenario. It's so minor, we have chosen not to
scan for it in our Log4shell scanning tool. We hope the focus will remain on fixing
the far more critical vulnerabilities in earlier versions.
In this post, we'll look at the motivations and repercussions of hyping up this far less serious attack vector. Then, we'll look at a timeline of the vulnerabilities discovered in log4j, ending with this latest vulnerability.
Capitalizing on the Panic
Before a CVE was assigned to the RCE discovered in CVE-2021-44832, the Checkmarx security researcher @YNizry released a tweet teasing about a "Log4j 2.17.0 RCE". Teams in charge of responding to these security disclosures with their ear to the ground anxiously await for the latest Log4j version to be released. After the disclosure, Checkmarx wrote a blog post with misleading information about the severity of this vulnerability. In the section, "Why is it so critical?", they compare their vulnerability to the original Log4Shell vulnerability, stating:
As you can see, using a different attack vector, it is still possible to achieve an arbitrary code execution using the default configuration.
With as much attention as there is now on the Log4j project, it can be difficult to truly understand the impact of the recently disclosed vulnerabilities when they are being compared against the original Log4Shell vulnerability, which has a perfect 10/10 severity. The truth is that this vulnerability, while technically an RCE, is incredibly unlikely to be jeopardizing to anyone's project. It requires the attacker to have a privileged position, at which point they would probably prefer another attack vector to further compromise a system.
Checkmarx has since backpedaled to update their post to reflect the highly specific attack scenario in which this vulnerability could exist. @YNizry has also apologized on Twitter for the concern that their original tweet raised in the security community.
Many security companies are eager to sell their products to panicking companies that are struggling to fix vulnerabilities. Stoking the fire with attention grabbing headlines referring to "yet another remote code execution vulnerability" with no other context is purely a capitalization on people's fear and confusion around one of the worst vulnerabilities in history.
We will never discourage anyone from updating their library version to one that is more secure. However, it is important to consider the urgency with which to push for version changes. Urging developers to update for the sake of updating to the latest version costs social capital with other teams. Crying wolf, just like the fable tells us, doesn't build trust.
With all the recent Log4j versions being released, it can be quite confusing what guidance to follow to have a fully patched system. Our mitigation guide is continually updated with up-to-date guidance.
The Troubling Timeline for On-Calls
To really understand why tweeting about a new RCE in Log4j without any context caused such distress to people, you must consider the timeline of how this has unfolded. You need not look further than the Log4j security advisory page to understand just how chaotic the past few weeks have been, but this is also merely a snapshot of the information which has been shared back and forth across the Internet.
It has been a busy month for security teams.
November 24th - Log4Shell Vulnerability Reported
The vulnerability was reported privately to the Log4j team by Chen Zhaojun of the Alibaba Cloud Security Team.
December 4th - Pull request created to fix Log4Shell
A public pull request was created to fix the Log4Shell vulnerability. It is important to note that a CVE has not been created yet and that the vulnerability is not very widely known about outside this PR.
December 10th - CVE Assigned for Log4Shell
The National Vulnerability Database assigns the Log4Shell vulnerability the identifier CVE-2021-44228 and gives it a severity of 10.0.
December 11th - 2.15.0 Released
2.15.0 is released to address CVE-2021-44228 - 10.0 (Log4Shell).
A public recommendation is made by the Log4j team to update to this version to fix the Log4Shell vulnerability.
Security teams have already started to investigate this issue internally as they have been made aware of this issue well before posts from different social media sites. Plans to address this issue internally are already underway for some companies.
December 15th - Version 2.16.0 Released to address CVE-2021-45046 - 3.7
Releases of versions
2.12.2 (for Java 7) are made. Four days have now passed since the release of
With a low severity, this has not been considered important, as efforts to update to
2.15.0 are well underway
for most companies, and shifting focus on this strategy can lead to confusion. Most likely, a number of security teams have pushed
for upgrading to
2.16.0 to fully have themselves covered.
December 18th - CVE-2021-45046 severity changed from 3.7 to 9.0 and Version 2.17.0 Released to address CVE-2021-45105 - 7.5
2.17.0 is released to address DOS vulnerability, but more importantly
2.15.0, the version initially recommended
upgrading to in order to prevent the Log4Shell vulnerability, contains an RCE with a
9.0 severity rating.
For those security teams that have been proactive in addressing the Log4Shell vulnerability, they now must ask developers
to instead update to at least
2.16.0 if they wish to prevent a possible RCE. Teams that had started to push for
may ask their developers to update once again to
2.17.0 out of caution. Keep in mind that it has been a least a week
since initial efforts were made to address this issue.
December 28th - Version 2.17.1 Released to address CVE-2021-44832 - 6.6
2.17.1 is released
to address an RCE vulnerability given a very specific circumstance where the attacker is in a
privileged position and can control the logging configuration.
Seeing "RCE" in this vulnerability description can be quite confusing now. The initial Log4Shell vulnerability is an RCE in probably the last library you would consider to actually contain an RCE. The fix to this was proven by the security community to still be widely exploitable. The fix to the fix is now once again proven exploitable.
Considering this by itself, one is lead to believe that another significant effort is needed to update systems, more than two weeks after the initial push. Of course, this is all happening during the holidays when a number of critical employees are possibly getting called in to work to assess what needs to be done.
For those interested, LiveOverflow has put together a great video detailing the history of other Log4j vulnerabilities leading up to Log4Shell, and the disconnect between security and software development.
Fixing Vulnerabilities without the Panic
Unclear messaging, incomplete fixes, and misleading severity have been prevalent through this entire patching process. Responding to the situation without considering how your own messaging can affect other teams can be more damaging than helpful.
Having worked on security teams for large companies, we understand how important clear concise guidance is when executing a plan for mitigation. All of these changes in messaging around safe log4j versions are going to make it hard for teams to know the right action to take. We are concerned that it could leave some services, which were updated initially to address Log4Shell, out of date with the latest recommendation.
We have written about how security companies have been jumping at opportunities to make money in this time of panic, and the truth is that we have similar incentives. Getting people to care about vague worst-case scenarios is hard, and a critical vulnerability makes it obvious why companies do need to care about security.
The distinction between the approach we take, and the approach taken by companies like Checkmarx, is in the value we provide. LunaSec isn't a tool which just surfaces vulnerabilities and leaves it up to developers to decipher an alert like: "CVE-2021-44832 was found in your code, fix it now!". We know from experience this simply doesn't work.
Instead, our Open Source product mitigates vulnerabilities by shrinking the blast radius when the inevitable hack happens. Because data in LunaSec is tightly monitored and protected against a full system compromise, there is more time to address security issues, without panic.
We want the teams in charge of responding to security incidents to be able to walk into a meeting and confidently say, "Our data is safe".
Senior engineers will be skeptical of any claim a product makes about security, and that is why our code is fully Open Source under Apache 2.0. Take a look at our documentation, have an engineer review our code, and prove to yourself that it isn't snake oil.
Thanks for reading, and good luck out there!