Gal Singer, a researcher at Aqua has written about the bug that he found in containerd. The bug (CVE-2020-15157) is located in the container image-pulling process. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.
The bug is in the container image-pulling course of action
Containerd is an industry-standard container runtime that is available as a daemon for Linux and Windows. It manages the complete container lifecycle of its host system including image transfer and storage, container execution and supervision, low-level storage, and network attachments.
The new CVE includes manipulation of the image manifest, allowing attackers to craft an image that can leak the host’s registry or cloud credentials when pulled from a registry. In other words, the manifest supports an optional field for an external URL from which content may be fetched, and it can be any registry or domain. This feature is the vulnerable part of the image-pulling process in containerd.
Singer pushed an image to a GCR registry, then pull it from a GKE cluster running vulnerable containerd to simulate the attacks. He saw see a ‘Basic Auth’ header, while looking at our ‘nginx’ weblog. “If we decode it (‘base64’), it turns out to be an authentication token. In our simulation, it is a GCP Service Account OAuth token” he said.
National Vulnerability Database also explained the bug as,
“If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control, and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image,” according to the bug advisory. “In some cases, this may be the user’s username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account.”
As Gal Singer said, it is always good practice to periodically verify that you’re using the latest version of the software, as is the case here. This vulnerability was patched in containerd 1.2.4, and containerd 1.3.x was also tested and validated as not vulnerable.