Amazon Web Services (AWS) has fixed four security issues in its hot patch from December that addressed the critical Log4Shell vulnerability (CVE-2021-44228) affecting cloud or on-premise environments running Java applications with a vulnerable version of the Log4j logging library or containers.
The hot patch packages from Amazon are not exclusive to AWS resources and allowed escaping a container in the environment and taking control of the host. The flaws could also be exploited through unprivileged processes to elevate privileges and execute code as with root permissions.
The vulnerabilities are currently tracked as CVE-2021-3100, CVE-2021-3101, CVE-2022-0070, and CVE-2022-0071. All of them have been assessed as high-severity risks with a score of 8.8 out of 10.
Hot patch trouble
Security researchers at Palo Alto Network’s Unit 42 discovered that Amazon’s Log4Shell hot-fix solutions would keep searching for Java processes and patch them on the fly without ensuring that the patched processes run under the restrictions imposed to the container.
“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 researchers explain
They add that “the malicious “java” process could then abuse its elevated privileges to escape the container and take over the underlying host.”
“Containers can escape regardless of whether they run Java applications, or whether their underlying host runs Bottlerocket, AWS’s hardened Linux distribution for containers. Containers running with user namespaces or as a non-root user are affected as well” – Palo Alto Networks
Another problem created by Amazon’s patch was that host processes were treated similarly, all of them getting elevated privileges during the Log4Shell fixing process.
Potentially, a malicious actor could plant an unprivileged process binary named “java” and trick the fixing service into executing it with elevated privileges.
The Unit 42 team has also published the following proof-of-concept (PoC) exploit video to demonstrate the container escape scenario:
The implementation details have been hidden on purpose to prevent threat actors from immediately using it in attacks and to give admins time to apply the available security updates.
Finding and fixing the flaws
Researchers at Palo Alto Networks identified the security issues on the AWS fixes six days after their release of the hotfix and informed Amazon on December 21, 2021.
The AWS security team acknowledged the vulnerabilities and attempted to fix them with a new update on December 23, 2021, but the changes proved to be insufficient.
In the months that followed, Unit 42 provided more information on how they bypassed the new fixes and on April 4, 2022, the remaining issues were minimal.
On April 19, 2022, AWS released the final updates for its Log4Shell patching solutions, which admins can apply via one of the following ways:
- Kubernetes users can deploy the latest version of Daemonset, which won’t affect the Log4Shell patch
- Hotdog users can upgrade to the latest version available
- Standalone hosts can upgrade by using the commands:
"yum update log4j-cve-2021-44228-hotpatch" (RPM)
"apt install --only-upgrade log4j-cve-2021-44228-hotpatch" (DEB)The four vulnerabilities in the Log4Shell hot-patch, discovered by Palo Alto Networks’ Unit 42 are described as follows:
- CVE-2021-3100: Privilege escalation arising from failure to mimic the permissions of the patched JVM, allowing any process to run with unnecessary high privileges (CVSS base score: 8.8)
- CVE-2022-0070: Incomplete fix for CVE-2021-3100
- CVE-2021-3101: Hotdog not respecting device restrictions, syscall filters, and resource limits on the target JVM, potentially leading to malicious modifications, policy overrides, and resource exhaustion (CVSS base score: 8.8)
- CVE-2022-0071: Incomplete fix for CVE-2021-3101
Amazon has also released a new advisory on the above vulnerabilities, providing official guidance to address the issues.
Unit 42 warns not to prioritize fixing container escape flaws against Log4Shell because the Log4j vulnerability is more severe and actively exploited.
Source: www.bleepingcomputer.com