A vulnerability in one of the Go libraries that Kubernetes is based on could lead to denial of service (DoS) for the CRI-O and Podman container engines.
The bug (CVE-2021-20291) affects the Go library called “containers/storage.” According to Aviv Sasson, the security researcher at Palo Alto’s Unit 42 team who found the flaw, it can be triggered by placing a malicious image inside a registry; the DoS condition is created when that image is pulled from the registry by an unsuspecting user.
“Through this vulnerability, malicious actors could jeopardize any containerized infrastructure that relies on these vulnerable container engines, including Kubernetes and OpenShift,” Sasson said in a Wednesday posting.
CRI-O and Podman are container engines, similar to Docker, that are used to perform actions and manage containers in the cloud. The containers/storage library is used by CRI-O and Podman to handle storage and download of container images.
When the vulnerability is triggered, CRI-O fails to pull new images, start any new containers (even if they are already pulled), retrieve local images lists or kill containers, according to the researcher.
Podman meanwhile will fail to pull new images, retrieve running pods, start new containers (even if they are already pulled), exec into containers, retrieve existing images or kill existing containers, he said.
The impact could be fairly wide: “As of Kubernetes v1.20, Docker is deprecated and the only container engines supported are CRI-O and Containerd,” Sasson explained. “This leads to a situation in which many clusters use CRI-O and are vulnerable. In an attack scenario, an adversary may pull a malicious image to multiple different nodes, crashing all of them and breaking the cluster without leaving a way to fix the issue other than restarting the nodes.”
Weaponizing Container Pulls
When a container engine pulls an image from a registry, it first downloads its manifest, which has the instructions on how to build the image. Part of that is a list of layers that compose the container file system, which the container engine reads and then downloads and decompresses each layer.
“An adversary could upload to the registry a malicious layer that aims to exploit the vulnerability and then upload an image that uses numerous layers, including the malicious layer, and by that create a malicious image,” Sasson explained. “Then, when the victim pulls the image from the registry, it will download the malicious layer in that process and the vulnerability will be exploited.”
Once the container engine starts downloading the malicious layer, the end result is a deadlock.
“[This] is a situation in which a lock is acquired and never gets released,” explained Sasson. “This causes a DoS since other threads and processes stop their execution and wait forever for the lock to be released.”
He listed the steps that happen when the vulnerability is triggered:
- Routine 1 – Downloads the malicious layer from a registry.
- Routine 1 – Acquires a lock.
- Routine 2 – Decompresses the downloaded layer using the xz binary and writes the output to stdout.
- Routine 3 – Waits for xz to exit and for all the data in stdout to be read. When the conditions are met, it continues and closes a channel called chdone.
- Routine 1 – Uses the output of xz as input and tries to untar the data. Since the file is not a tar archive, untar fails with “invalid tar header” and doesn’t finish reading the rest of the data from xz’s stdout. Since the data will never be read, routine 3 is now deadlocked and will never close chdone.
- Routine 1 – Waits for routine 3 to close chdone and is also deadlocked.
Once routine 1 is deadlocked, the container engine cannot execute any new requests because in order to do so, it needs to acquire the lock on step 2, which will never be freed.
Patches for the bug were issued in version 1.28.1 of containers/storage; CRI-O version v1.20.2; and Podman version 3.1.0. Admins should update as soon as possible.
Container Security in the Spotlight
Cloud container security continues to be a focus for users – and for cyberattackers. For instance, earlier in April an organized, self-propagating cryptomining campaign was uncovered that targeted misconfigured open Docker Daemon API ports. Thousands of container-compromise attempts were being observed every day related to the campaign.
Also in April, Microsoft’s cloud-container technology, Azure Functions, was found to harbor a weakness that allows attackers to directly write to files, researchers said. It’s a privilege-escalation vulnerability that could ultimately allow a user to escape the container.
And, in a vivid example of why cloud infrastructure needs strong security, a simple Docker container honeypot was used for four different criminal campaigns in the span of 24 hours, in a recent lab test.
Ever wonder what goes on in underground cybercrime forums? Find out on April 21 at 2 p.m. ET during a FREE Threatpost event, “Underground Markets: A Tour of the Dark Economy.” Experts from Digital Shadows (Austin Merritt), Malwarebytes (Adam Kujawa) and Sift (Kevin Lee) will take you on a guided tour of the Dark Web, including what’s for sale, how much it costs, how hackers work together and the latest tools available for hackers. Register here for the Wed., April 21 LIVE event.
