Hot patches made available by Amazon Web Services (AWS) in response to the recent Log4j vulnerabilities could be exploited for privilege escalation or to escape containers, according to Palo Alto Networks.
Apache Log4j vulnerabilities disclosed in December 2021, including the one tracked as Log4Shell, can allow attackers to remotely execute arbitrary code and take control of vulnerable systems.
In response to these flaws, AWS released multiple hot patches – each suitable for a different environment, including servers, Kubernetes, Elastic Container Service (ECS) and Fargate – that would keep track of vulnerable applications and containers and patch them on the fly.
Researchers from Palo Alto Networks’ Unit42 discovered that, once the hot patch had been installed, any container on the server or cluster could exploit it to take over the underlying host. Furthermore, unprivileged processes could exploit the hot patches to elevate privileges and execute code as root.
Starting December 2021, AWS released three hot patching solutions: one bundled in an RPM or Debian package, a hot patch Daemonset for Kubernetes clusters, and one bundled as a set of OCI hooks and meant for Bottlerocket hosts (called Hotdog).
“After any one of the patches is installed to a host or cluster, new containers can exploit the patch to escape and compromise their underlying host. On hosts that installed either the hot patch service or the hot patch Daemonset, existing containers can escape as well,” Unit42 says.
To patch JavaScript processes on the fly, the solutions invoke certain container binaries, and the researchers discovered that they did so without proper containerization, meaning that the limitations that typically apply to container processes would not apply to the new processes as well.
[ READ: Fewer-Than-Expected Log4j Attacks, but Mirai Joins the Fray ]
“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,” the researchers explain.
The hot patch solutions treated unprivileged processes in a similar manner, meaning that a malicious unprivileged process could create a binary named “java” and abuse the hot patch service to elevate its privileges.
“The issues are exploitable regardless of the container configuration, so even environments that enable advanced isolation techniques like running containers in user namespaces or as a non-root user are affected,” Unit42 notes.
The security researchers also warn that, because hot patches might have been deployed at scale in the wake of Log4Shell, numerous container environments might have been exposed to security risks, and some may continue to be impacted, given that users might have kept the hot patch running even after other fixes were rolled out.
A total of four issues were identified, tracked as CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 and CVE-2022-0071. Fixes that AWS issued on April 19 eliminate the container escape and privilege escalation possibilities.
Users are encouraged to apply the fixed hot patch solutions as soon as possible, especially in multitenant container environments and clusters that run untrusted images.
Related: CISA Unaware of Any Significant Log4j Breaches in U.S.
Related: Log4Shell-Like Vulnerability Found in Popular H2 Database
Related: SAP Patches Log4Shell Vulnerability in More Applications