runC Major Security Flaw Patched At Record Time, All Container Admins Expected To Update

Virtual Patching vs Unpatched Vulnerabilities Unleashed by Trend Micro

A major security flaw under CVE-2019-05736 that has affected runC is now patched, thanks to the hard work of its developers. The vulnerability enabled a guest container’s root privileges to create a side effect root powers for the host system. In other words, it was a critical flaw where a privilege guest access in a container also gave the user privileged access to the host, a capability that should never be available for any item or user inside the guest container.

Those who will refuse to update to a safer version of runC will risk the possibility of a malicious user from a guest container to interfere with the operations of the host. This includes running malicious software, encrypt files, extract files from the host and sending them to an unknown destination. In the Linux platform, the ‘memory’ of the guest container is exposed to the host as /proc/self/exe. With an unpatched runC, the guest container has more privilege than it should be, which is one of the worst ways to cause trouble and be in trouble, with unauthorized programs and data are executed to the host, from the guest.

There are quite a few circumstances where /proc/self/exe pointing to a pretty important container binary is a _bad_ thing, so to avoid this we have to make a copy (preferably doing self-clean-up and not being writeable). We require memfd_create(2) — though there is an O_TMPFILE fallback — but we can always extend this to use a scratch MNT_DETACH overlayfs or tmpfs. The main downside to this approach is no page-cache sharing for the runc binary (which overlayfs would give us) but this is far less complicated. This is only done during nsenter so that it happens transparently to the Go code, and any libcontainer users benefit from it. This also makes ExtraFiles and –preserve-fds handling trivial (because we don’t need to worry about it),” explained Aleksa Sarai and Christian Brauner, main developers of runC, in their official GitHub page where the official fixed version can be downloaded.

Docker, a popular container system released version 18.09.2, with the updated runC version included. Kubernetes, its competitor which also bundles the runC library also published an instruction on their official site on how to cease from being vulnerable. “Kubernetes in turn sits on top of those tools, and so while no part of Kubernetes itself is vulnerable, most Kubernetes installations are using runc under the hood. Another potential mitigation is to ensure all your container images are vetted and trusted. This can be accomplished by building all your images yourself, or by vetting the contents of an image and then pinning to the image version hash (image: external/someimage@sha256:7832659873hacdef). Upgrading runc can generally be accomplished by upgrading the package runc for your distribution or by upgrading your OS image if using immutable images,” explained the Kubernetes representative.

Those who maintain their own installation of runC will encounter update packages for their Linux distribution:

  • Ubuntu – runc 1.0.0~rc4+dfsg1-6ubuntu0.18.10.1
  • Debian – runc 0.1.1+dfsg1-2
  • RedHat Enterprise Linux – docker 1.13.1-91.git07f3374.el7 (if SELinux is disabled)
  • Amazon Linux – docker 18.06.1ce-7.25.amzn1.x86_64
  • CoreOS – 2051.0.0

Julia Sowells960 Posts

Julia Sowells has been a technology and security professional. For a decade of experience in technology, she has worked on dozens of large-scale enterprise security projects, and even writing technical articles and has worked as a technical editor for Rural Press Magazine. She now lives and works in New York, where she maintains her own consulting firm with her role as security consultant while continuing to write for Hacker Combat in her limited spare time.

0 Comments

Leave a Comment

Login

Welcome! Login in to your account

Remember me Lost your password?

Don't have account. Register

Lost Password
Register