New containerd Security Hole Needs to Be Patched ASAP
These days most of us are using the containerd runtime to manage our container’s lifecycle. It does, after all, underlay both Docker and many common Kubernetes configurations. That, of course, means we need to pay especially close attention to any possible containerd security issues. Alas, the UK security company NCC Group, has uncovered a potentially nasty one: CVE-2020-15257, containerd-shim API Exposed to Host Network Containers.
The containerd-shim is a binary spawned by containerd. This serves as the parent of a container. It implements the container lifecycle and reconnection logic. This, in turn, uses the containerd shim API as a network connection to containerd. So far, so normal.
But, this connecting process had an effective UID of 0–aka root–but did not otherwise restrict access to its domain socket. Whoops. Thanks to this, non-user namespaced containers with host networking can access this API and cause containerd-shim to perform dangerous actions and spin up arbitrarily privileged containers, enabling container escapes and escalation to full root privileges on the host.
Did I say whoops? Let me say it again: Whoops.
There’s nothing quite like a security hole, which enables an attacker to relatively easily gain root access to make people sit up and take notice.
Sure, it’s best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. Indeed, the containerd maintainers strongly advise against sharing namespaces with the host. That said, I’ve seen way, way too many containers running as root. If you’re not practicing good security, you may be vulnerable.
As Red Hat security put it, even though OpenShift uses the cri-o container runtime and is thus immune, “This could allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.”
Thus Red Hat “awarded” this bug a Common Vulnerability Scoring System (CVSS) score of 8.8. That’s high, which. while it may not be in the “fix it now” critical rating, is more than worrying enough.
So, what can you do about it. First, it’s been fixed in containerd 1.3.9 and 1.4.3. These patches were released recently. And you should update to these versions as soon as you can. You’ll also have to restart any containers that spun up before you make the fix. That’s because older running containers will continue to be vulnerable even after an upgrade.
While you’re at it, stop running containers as root and in the root network namespace. Even if you patch now and you dodge this bullet, you may not be so lucky when the next serious containerd security bug fires.
The Cloud Native Computing Foundation and Red Hat are sponsors of The New Stack.
Feature image from kiwikong de Pixabay.
