Over the last few days, there have been a tremendous amount of posts about the Log4j 2 vulnerability, with Wired going so far as claiming that, “the internet is on fire.” Tl;dr: LogDNA is not exposed to risk from the Log4Shell vulnerability in Log4j 2 at this time. If that’s all you came for, you can stop reading here. If you want to learn more about the vulnerability and how LogDNA protects you from risks like these, grab a cup of coffee and read on.
Log4j 2 is an open-source logging utility from Apache Logging Services. The Log4j Java library dates back to 2001 and provides a feature-rich set of logging options for Java that can be used in different ways to control what detail from an application is logged, to where, and how. It is typically used for supporting functions inside an application and not as a standalone service. The “2” is a version increment to Log4j that occurred in 2014 to address issues with the original version and add a plugin architecture among other improvements.
Over the last few days, a critical vulnerability (CVE-2021-44228) impacting the Log4j 2 utility was reported. The vendor says that this vulnerability has been addressed in Log4j 2.15.0. On Thursday, December 9, 2021, CrowdStrike said that, “active exploitation has been identified in the wild (ITW). At the time of this writing, CrowdStrike Falcon OverWatch™ and external sources confirm active and ongoing attempts to exploit CVE-2021-44228,” warning people to “patch as soon as possible.”
Leaders in the cybersecurity industry like Free Wortley, CEO of the open source data security platform LunaSec, have been quoted exclaiming, “It's a design failure of catastrophic proportions.” Dave DeWalt, vice chair of the LogDNA board of directors and co-founder of NightDragon, who recently led our series D, said, “The severity of this vulnerability is unprecedented. Organizations everywhere need to take immediate action to secure their environments.”
As part of ongoing security due diligence, LogDNA regularly scans to validate that the versions of code we have running in production are consistently kept up to date. As such, the engineering and platform teams evaluated our platform and clients immediately when the vulnerability was made known and determined we are not exposed to the Log4Shell vulnerability from Log4j 2 at this time.
We confirmed that our platform is running with the correct version of the Java Virtual Machine (JVM) and the necessary settings are in place. We are applying the other recommended settings as a proactive additional layer of security in a staged manner to avoid any downtime for our customers.