Hot Log4jShell Fix from AWS Needs a Fix on Kubernetes Clusters

Amazon Web Services (AWS) this week, after being alerted by Unit 42 security researchers at Palo Alto Networks, made available an update to a hot fix for the Log4jShell vulnerability found in Java applications created by the cloud service providers that inadvertently made it possible for every container in a Kubernetes cluster to take over the underlying host.

Ariel Zelivansky, director of security research at Unit 42, said it’s not likely that cybercriminals have exploited this vulnerability given the subtlety of the flaw and the level of expertise required to compromise it, but if the original hot fix is not removed from a Kubernetes cluster, a security risk remains. In addition to taking over the underlying host, unprivileged processes can also exploit the patch to escalate privileges along with gaining root code execution. Some IT teams might have applied the latest version of the hot fix from AWS without remembering to remove the original, he noted.

Containers can escape regardless of whether they run Java applications, or whether the host runs Bottlerocket, a hardened Linux distribution for containers from AWS.

AWS created its hot fix for the Log4jShell vulnerability and then made it freely available to any organization running Log4j log management software on any platform. The vulnerability discovered by Unit 42 researchers only affects the version of that hot fix that was made available as a container. The flaw in the fix is not as egregious as the original Log4jShell flaw, and Unit 42 researchers have assigned CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 and CVE-2022-0071 to track the vulnerabilities. Containers running with user namespaces or as a non-root user are affected as well.

The vulnerability discovered by Unit 42 researchers is yet another example of why organizations need to adopt modern IT incident management practices based on DevSecOps principles. Each time there is a zero-day vulnerability of that magnitude of Log4jShell there is always going to be a rush to implement a hot fix before cybercriminals can find and exploit a vulnerability. Each of those fixes, however, has been developed in a rush, so it’s likely they may not have been vetted as well as a patch that has been under development for months. Each fix needs to be reviewed for any potential security flaw, because there was simply not enough time for security experts to test the hot fix before it was applied.

The challenge, of course, is that in the absence of a software build of material (SBOM) many IT teams are unsure of what software modules are running precisely where in distributed IT environments, an issue that is further compounded when containers encapsulating those modules are continuously ripped and replaced.

While most IT teams have some form of an IT incident management capability, most are not designed to deal with zero-day vulnerabilities that, unfortunately, are becoming increasingly more common. IT teams can find themselves spending weeks looking for all the instances of a software package that might have been impacted by a vulnerability that was disclosed with no advance warning. A modern approach to incident management defines a set of best practices that ultimately makes it less stressful to respond to the disclosure of a zero-day vulnerability.