RunC Vulnerability Makes Container SysAdmin’s Worst Nightmares a Reality

• Security researchers have discovered a “breakout” vulnerability that affects major cloud services.
• Patches are rolling out in a deluge of fixing frenzy, as the severity of the vulnerability has placed everyone in high risk.
• Once again, diligent sysadmins are outside the spectrum of affection of this vulnerability.

The worst-case scenario for a container is to have a malicious container somehow gain access to the host system. This is exactly what the CVE-2019-5736 RunC vulnerability allows, as a user can execute code on the host with root-level permissions, overriding SELinux and AppArmor policies. Since RunC container runtime is used by Docker, Kubernetes, and other container platforms like LXC and Apache Mesos, it is a fundamental vulnerability in a core component that has been with us all along and was only now discovered. Administrators of container-hosting systems are urged to patch their container implementations immediately.

The positive side of the story is that the vulnerability was discovered by two security researchers, namely Adam Iwaniuk and Borys Poplawski, so the fixes could be rolled out before malicious attackers could wreak havoc to containers and cloud services worldwide. The researchers discovered that the vulnerability allowed a malicious container to overwrite the host’s RunC binary, allowing the attacker to create new malicious containers or attach to an existing container which the attacker had previous write access to. By doing this, an attacker could bring chaos to many thousands of containers that are under the same container host.

All major cloud service providers are currently rolling out the patches or have at least published a guideline on how to deal with this issue until the patches are available. For example, Google Cloud warns that Kubernetes nodes are affected but COS is safe, while Amazon advises customers to launch new instances from the latest AMI version that they have updated. As the researchers point out, those who were doing the correct use of user namespaces by not mapping the host root into the container’s user namespace are not vulnerable to this problem. However, lazy sysadmins are notoriously known for not following proactive safety practices like the above.

A Red Hat representative has clarified that SELinux in enforcing mode is thoroughly addressing the risk of the discovered vulnerability by handling the container processes in a more safe manner. Again, maintaining SELinux is extra work for sysadmins, so they tend to refrain from doing it.

Considering the severity and possible spectrum of affection and container compromise, patching is crucial right now. It has been years since such a dangerous “breakout” vulnerability on containers was discovered, but once again, the fact that things that are practically possible can stay covered for long remains unchanged and signifies how security should be handled at all times. That is, by taking all proactive protection measures and applying all “sensible methods” wherever possible.

Do you think that containers may hide more severe vulnerabilities like this one? Let us know of your thoughts in the comments below, and don’t forget to check out our social communities on Facebook and Twitter.