AWS Log4Shell hot patch vulnerable to privilege escalation

Amazon's initial Log4Shell fix had 'severe security issues,' a Palo Alto Networks security researcher said. Amazon released new patches to fix those issues Tuesday.

An AWS hot patch released in December to address the Log4Shell vulnerability is vulnerable to privilege escalation and container escape vulnerabilities, according to research published Tuesday by Palo Alto Networks.

Log4Shell is a nickname for CVE-2021-44228, a critical vulnerability affecting popular Java logging framework Log4j 2. First reported last December, the flaw enables threat actors to easily and remotely execute malicious code against organizations with certain configurations. The vulnerability is considered particularly problematic because Log4j is a ubiquitous piece of software present in a wide number of products and services. The vulnerable configurations are also standard on older versions of Log4j.

Amazon's first hot patch for AWS was released Dec. 12. It mitigated both the Log4Shell vulnerability and a related denial-of-service flaw that popped up soon after (CVE-2021-45046). However, as Palo Alto Networks' threat intelligence team Unit 42 discovered, issues with the hot patch left vulnerable AWS customers exposed to privilege escalation and container escape bugs.

These vulnerabilities were designated three CVEs: CVE-2021-3100, CVE-2021-3101 and CVE-2022-0070.

Amazon released new hot patches for Amazon Linux and Linux 2 on Tuesday; both Amazon and Unit 42 recommended AWS customers update to this latest version. Timed with the release of the patch, Unit 42 detailed the initial patch's issues in a detailed technical post written by Palo Alto Networks principal security researcher Yuval Avrahami.

According to Avrahami, Unit 42 researchers found "severe security issues" in the initial patch, and after installing it to a server or cluster, "every container in that environment can exploit it to take over its underlying host."

"For example, if you installed the hot patch to a Kubernetes cluster, every container in your cluster can now escape until you either disable the hot patch or upgrade to the fixed version," he wrote. "Aside from containers, unprivileged processes can also exploit the patch to escalate privileges and gain root code execution."

The cause, according to the post, has to do with how the patch works; it continuously searches for Java processes and patches them against Log4Shell.

"The issue was that they invoked container binaries without properly containerizing them. That is, the new processes would run without the limitations normally applied to container processes," he wrote. "A malicious container therefore could have included a malicious binary named 'java' to trick the installed hot patch solution into invoking it with elevated privileges. The malicious 'java' process could then abuse its elevated privileges to escape the container and take over the underlying host."

Avrahami added that with these flaws, organizations are vulnerable to container escape, regardless of whether the servers run Java applications or whether their host runs Bottlerocket, the Linux-powered AWS operating system used for running containers. Additionally, "Containers running with user namespaces or as a non-root user are affected as well."

Amazon has not responded to SearchSecurity's request for comment at press time.

Alexander Culafi is a writer, journalist and podcaster based in Boston.

Dig Deeper on Cloud security

SearchCloudSecurity
SearchNetworking
SearchCIO
SearchEnterpriseDesktop
SearchCloudComputing
ComputerWeekly.com
Close