Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5). Snyk is currently not aware of any fully-fledged PoCs or exploits in circulation. CVE-2021-45105 has been issued, and a new fixed version (2.17) has been published by Apache which we recommend upgrading to.

Snyk’s Research team is staying on top of this dynamic Log4j situation and will continue to provide vulnerability details the moment we know about them. 

Should I move up to the new version?

It’s always important to eliminate vulnerabilities in your applications, but since there have been a few in the Log4j library, we should put this one into perspective. This is a Denial of Service vulnerability rather than an arbitrary code execution like the previous two, so the potential risk is less severe. The most important observation here is the exploitability. The previous two vulnerabilities were very clearly exploitable with mature and functional exploit examples that proved this. While there is potential for this new Denial of Service vulnerability to be exploited, it’s unclear how easy or common this could be at the time of writing with the current available data. 

In summary, if you can and have time to remediate this vulnerability, you should move up to version 2.17.0, but making sure all your Log4j versions are at a minimum 2.16.0 is more important to mitigate the arbitrary code execution risk, before moving all to 2.17.0. If you still have services that are yet to be upgraded, then it makes sense to jump straight up to the latest 2.17.0 version to fix all the Log4j issues that have been disclosed recently.

Why are there so many Log4j vulnerabilities all of a sudden?

For those wondering why there are so many rapid disclosures and corresponding releases in this library, it’s important to understand the full context of what is happening, and why it makes sense that new upgrades have been, and might still be, released.

1. Increased community exposure – the initial disclosure of the critical Remote Code Execution in Log4j has pulled in the community at large onto this project. As such, many bugs that might have been overlooked previously are now coming to light thanks to the efforts of the Java open source community. This community exposure has been spilling over into other similar projects as well, sometimes to mixed results, as the haste to help disclose potential vulnerabilities gets ahead of community consensus.

1. Rushed initial security fix – while the exact events leading up to the disclosure of CVE-2021-44228 are still being understood, it would appear that the normally maintained responsible disclosure window was not strictly adhered to, as details of this vulnerability were leaked to the public before a full fix was ready. The Apache team had to release a fix for the vulnerability as quickly as possible. This led to additional vectors and issues being identified, resulting in the subsequent releases.  

1. Backward compatibility – Log4j is a core component of the Java ecosystem. There is a need for any new version to maintain backward compatibility with previous versions to avoid unnecessary breakage, potentially leaving users unable to upgrade to the new and safe version. Unfortunately, this necessary and cautious approach means the core functionality can’t be altered whole-scale. Therefore, additional attack vectors or workarounds undiscovered at the time of fix publication may exist and could be exposed as the community continues to review the threat landscape.

What can I do to make this easier going forward?

Considering the above context, it’s likely we will see additional vulnerabilities and corresponding version releases in the near future. It’s important for users of Log4j (and other open source packages) to be prepared for this eventuality. Here are some best practices to improve your AppSec program to make these zero-day events easier to manage:

• Scan code daily to find the latest vulnerabilities in managed and even unmanaged code
• Create an SBOM to keep track of your software supply chain
• Set up automated CI/CD DevOps Pipelines with integrated application security
• Where possible, practice good open source hygiene by updating to more recent releases of packages. This way, any urgent security fixes are more easily upgraded to and will cause less churn to the compatibility of your project

Be sure to follow us on LinkedIn, Twitter, or Facebook to stay on top of all the latest Log4Shell and other critical vulnerability news.

SnykCon 2021 is a wrap!

Rewatch all your favorite talks and check out the talks that you weren’t able to attend live.