Slashdot Mirror
Doomsday Docker Security Hole Uncovered (zdnet.com)
An anonymous reader quotes a report from ZDNet: One of the great security fears about containers is that an attacker could infect a container with a malicious program, which could escape and attack the host system. Well, we now have a security hole that could be used by such an attack: RunC container breakout, CVE-2019-5736. RunC is the underlying container runtime for Docker, Kubernetes, and other container-dependent programs. It's an open-source command-line tool for spawning and running containers. Docker originally created it. Today, it's an Open Container Initiative (OCI) specification. It's widely used. Chance are, if you're using containers, you're running them on runC.
According to Aleksa Sarai, a SUSE container senior software engineer and a runC maintainer, security researchers Adam Iwaniuk and Borys Popawski discovered a vulnerability, which "allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root." To do this, an attacker has to place a malicious container within your system. But, this is not that difficult. Lazy sysadmins often use the first container that comes to hand without checking to see if the software within that container is what it purports to be. Red Hat technical product manager for containers, Scott McCarty, warned: "The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies...and that's exactly what this vulnerability represents."
According to Aleksa Sarai, a SUSE container senior software engineer and a runC maintainer, security researchers Adam Iwaniuk and Borys Popawski discovered a vulnerability, which "allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root." To do this, an attacker has to place a malicious container within your system. But, this is not that difficult. Lazy sysadmins often use the first container that comes to hand without checking to see if the software within that container is what it purports to be. Red Hat technical product manager for containers, Scott McCarty, warned: "The disclosure of a security flaw (CVE-2019-5736) in runc and docker illustrates a bad scenario for many IT administrators, managers, and CxOs. Containers represent a move back toward shared systems where applications from many different users all run on the same Linux host. Exploiting this vulnerability means that malicious code could potentially break containment, impacting not just a single container, but the entire container host, ultimately compromising the hundreds-to-thousands of other containers running on it. While there are very few incidents that could qualify as a doomsday scenario for enterprise IT, a cascading set of exploits affecting a wide range of interconnected production systems qualifies...and that's exactly what this vulnerability represents."
Containers are just computer programs. I never understood the hipster fascination with it.
and undocumented since it runs isolated from everything else, and doesn't have to be installed
run in the same machine (virtual or physical) as other software.
The Joyent cloud features a second layer of isolation. Sometimes you see this described as "double-hulled virtualization". The OS performance penalty to achieve this is low to non-existent due to the nature of BSD zones (hardened jails).
Joyent hybrid cloud: Triton Compute Service and Triton DataCenter integration
This is precisely the scenario that Joyent's technology exists to mitigate.
You think you're running Linux containers, but under the hood you've also got zones and ZFS snapshots.
There is a resource penalty involved in using a high-integrity file system like ZFS, (efficient copy-on-write requires extensive write-buffer coalescing) but it's often not a large one compared to the many gains in administrative security and ease.
Damnit, Jim, I'm a Docker, not a software engineer.
Wait, wut did I just say?
Check your premises.
I got a malicious container from the Container Store. I blame Marie Kondo.
Containers (the collection of Linux namespaces and cgroups) are not a strong enough security boundary to safely isolate untrusted code. They never have been, and anybody that told you otherwise is either lying or clueless. Containers are super convenient, and a great way to manage the deployment of your software, and you should use them -- Just not to protect mixed-trust workloads running on the same host from each other.
If you want to run code from sources that you don't trust, isolate it in a separate VM. If you want to use container-like workflows and orchestration systems to manage your VMs, use something like Kata Containers (https://katacontainers.io/).
The reality is that it can support both.
I have seen container images that live eternally and get randomly changed and 'docker committed' and no one is comfortable knowing how to get back to that state.
To the extent I have authority to do so, I make sure that images do not stray from a specific build process that comes from the same teams that release the OS platform and do not tolerate processes that involve 'change stuff in a container and commit to capture changes'. In that scenario it is a useful tool.
The parent laments at least resemble my dread: when a project talking about downloads gives only 'docker pull', then almost universally the software is crap held together by duct tape they barely could sort out to get run once. The preceding fad was 'virtual appliance', where the same thing held: developers lacking the competency to properly design their software to work sanely in a well controlled environment. Attempts to use those software have non-trivially more frequent incidents of falling over and no one on earth able to figure out what went wrong because they never unified how the software produces debug and they spew out in random places through third-party code the vendor doesn't really understand. Also they have a tendency to have some decrepit versions of software dating back to when they first did a 'docker pull' when they started development and never bothering to refresh dependencies.
Sure, there will be examples of well maintained software and people doing the right thing in dockerhub, but there are a lot of crappy things there too. Sometimes things will look quite nice at first and then after using and configuring you quickly enter a configuration they didn't think about and poof.
XML is like violence. If it doesn't solve the problem, use more.