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.
I think you're confused. "IT guys" generally aren't involved with engineering zero-days out of software. That's more of a software engineer thing. Unless your "IT guy" is a software engineer for Docker. In which case, it's strange to refer to him as an "IT guy" rather than a software engineer.
Wow! Y2K38 came early.
If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
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.
I like it. You call yourself an IT guy? is a little flat compared to you call yourself a software engineer?
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.
yes it's bad; but it is not the first docker escape and it won't be the last
it's also funny, because of the way it works: the bug in runc allows the container to overwrite the runc binary and inherit runc's root privileges
It makes doing stateless design easier.
http://www.drdobbs.com/architecture-and-design/containers-for-development/240168801
You stay away from my comfortable Docker slacks. Don't you put no doomsday security holes in my khaki slacks! I need them for work.
Rule 34. Never underestimate it. Poor Superman.
Captcha: adultery
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/).
I want that docking kind of love. Like penis in the foreskin kind of love.
âoechance areâ??!
Geez, doesnt anyone proofread this crap?
Docker is not about isolation, just ease of standing up an environment. If you want to have the security of isolating a Docker container from the host or other containers for that matter, you need to use a VM or BSD jails. I have services that ran execute arbitrary code, but they run as locked down users. Yet people have Docker running as root. This is just asking for trouble. Docker gives no guarantees about security, yet it runs as root and is expected to run whatever is inside of a container.
Docker is only about convenience, not security. Any security it so happens to have is arbitrary.
This is what we pay our IT guy an arm and a leg to prevent.
Where are you? I only get paid a hand and wrist, a full arm in itself would be awesome, PLUS a leg?! Sign me up!
I want that docking kind of love. Like penis in the foreskin kind of love.
That's called masturbation. You've had too much of that already
âoechance areâ??!
Geez, doesnt anyone proofread this crap?
Apparently you don't..
It's not a strong enough security boundary, but it damn well *should* have been. There's no problem doing this in FreeBSD and Solaris without paying a hardware virtualization performance tax. Frankly, the Linux community should be embarrassed that such a fundamental system facility was implemented in a botched and useless manner.
This is SO true. But the Docker crowd are too into new shiny to realize how utterly clueless they are and what a shambles the security posture is. 90% of the containers I see are running as fucking root!
It is literally as bad as Windows where every ISV requires local Administrator permissions just to run their ball-achingly bad calculator app.
How's life in the hypocrite lane?