Leaky Vessels flaws allow hackers to escape Docker, runc containers | Hacker News Reader

Leaky Vessels flaws allow hackers to escape Docker, runc containers

bleepingcomputer.com

63 pointsel_duderino25 comments

If you want more info, we have a detailed blog post on the Snyk website here: https://snyk.io/blog/leaky-vessels-docker-runc-container-bre... (we also built two open source detection tools you can use to see if anyone is taking advantage of these issues in your infrastructure): a static analysis tool and a runtime tool using eBPF.

Frankly if a user can run the docker command he is basically root anyways. That's why you do not add random users to the docker group.

Podman (and Docker) do rootless containers, which would limit privilege escalation from this vuln, too IIUC

Does container-selinux limit this container escape vulnerability?

Just this week there was a story[0] with a subthread about how Docker requires you to mount a volume, so it is better than launching shell scripts directly. I know all software has bugs, but Docker did not prioritize security and is unfit for isolation of untrusted code.

I will continue to stick with VMs as my security boundary.

[0] https://news.ycombinator.com/item?id=39240471

Just pointing out the most VM / virtualization platforms have also had security problems where an attacker could escape the VM and access the underlying operating system.

The major difference is that VM's are intended to be a security boundary as a primary function, and give you tools like hardware virtualization or enforcing single tenancy for a given NUMA node to reduce the attack surface.

KVM vulnerabilities are rare compared to Linux kernel LPEs, which makes sense, because KVM is a relatively small part of the Linux kernel compared to the system call and driver attack surface. Containers are great, but shared-kernel security isolation of standard Unix programs doesn't work.

Maybe I’m in the minority here, but I use containers for ease of packaging and deployment, security isn’t really my expectation for the container as I also rely on VMs for that aspect. I have a handful of long-running VMs with docker engine installed, and that serves as my application platform.

Definitely not the minority, anyone who needs secure isolation for a container should be wrapping it in a single tenant VM

Firecracker has often been recommended (here on HN and elsewhere) for a VM-for container-execution model : https://github.com/firecracker-microvm/firecracker

There's also Cloud Hypervisor, which is very similar, and based off some of the same crosvm code and ideas.

https://github.com/cloud-hypervisor/cloud-hypervisor

gvisor; `runsc`: https://gvisor.dev/docs/ :

> gVisor provides a virtualized environment in order to sandbox containers. The system interfaces normally implemented by the host kernel are moved into a distinct, per-sandbox application kernel in order to minimize the risk of a container escape exploit. gVisor does not introduce large fixed overheads however, and still retains a process-like model with respect to resource utilization.

https://news.ycombinator.com/item?id=38609105

kata containers: https://github.com/kata-containers :

> Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

I have seen this for ages and thought it was some design limitation. Didn't attempt to report it as vulneribility ...

oO This one is a clear vulnerability -- if you're able to escape a container and access the host system (usually with root access since Docker is running as root most places), that's a big issue.

Last I checked, Docker wasn't considered a security boundary and Docker escapes weren't considered a security issue. The most obvious escapes have slowly been mitigated over time, but the prevailing wisdom is that you should always assume that an attacker can work their way from the container to the host system. Obviously never put anything sensitive on a docker host, and assume anything running on the host (like the other docker containers) is running at the same privilege level.

I tried for a long time to even get docker to just give a config option to disable privileged mode with no success.

I even resorted to posting instructions on stack exchange demonstrating how to walk /sys to find device numbers and use mknod to read the hosts root volume and now as most servers don't mount their efi partition, how you could mount it rw inside a container with little effort.

Containers are namespaces and purely depend on privilege dropping for the security they provide.

Part of the problem is that container breakout is narrowly defined.

The fact that a privileged container can upload firmware or access private keys by reading the hosts root volume didn't count.

While the ability to disable privileged mode wouldn't have solved this issue it still would have reduced the attack surface. But will the projects refusal to even take that step I gave up.

Deciding that the only safe option was to consider containers as namespaces and nothing more.

Unfortunately adding persistence and other functionality tends to result people running it as uid0, which means that you have to consider as anything that can launch a container as having superuser privileges.

Podman uses crun by default but will use runc if unavailable.

Buildkit doesn't look too useful(?) with podman as some of its better features are built in to podman.

That's why it's better to run a docker container inside a micro vm I guess.

Why not just nix it?

Friendly reminder that containers aren't a security control and your threat modeling should already assume the host VM running any untrusted containers is compromised

Multi-tenancy, in any shape or form is sadly a potential security problem. I don't care if it's VM, containers, VLANs or databases, if you absolutely need to know that no one else is going to have access to your data, you need separate physical hardware.

In many circumstances you can make some tradeoffs, like running multiple customers or projects on the same vmware installation, because the risk is low or the other tenants are well known. I don't think Kubernetes is quite there yet where I'd trust multiple tenants on the same cluster.

Technically yes, but practically no. If you have the expertise to do it well, or cash to pay for someone else to do it well for you, you can definitely get trustworthy security boundaries without physical separation.

As an example, a VM from a reputable cloud provider is secure enough for most purposes, likewise I'd trust managed containers from a reputable cloud provider (except Azure, they have a dodgy track record when it comes to container security)

As an example of the difference directly related to k8s

"Security settings that you specify for a Container apply only to the individual Container, and they override settings made at the Pod level when there is overlap."

https://kubernetes.io/docs/tasks/configure-pod-container/sec...

While there are other Byzantine faults like this CSV, that should give you a hint.

The problem is that containers depend on good actors dropping privlages on a shared kernel.

Where VM's have a natural abstraction and their own kernel, containers require proper configuration of seccomp, apparmor, selinux, dropping privileges, etc... to reduce the attack surface.

An easy demonstration of this is to launch a privlaged container and run insmod with some random kernel module on the host OS.

In namespaces, you start with no isolation, and you add whatever you want or more realistically remember to add. They are not jails where you start with a reasonable secure baseline.

In fact the k8s 'baseline' pod security standard still has MKNOD caps which can result in issues like CVE-2021-25741. While /proc now has filtering /sys doesn't and you can find the major minor numbers of the hosts root filesystem and read it from a container.

It is not that containers can't be made reasonably secure, but that they aren't inherently secure. They are default allow all because they are inherently just namespaces implemented basically through value remapping.

Why is it all or nothing? It's absolutely a security control.

If you know what you're doing sure, you could justify it as one layer of security controls as part of a defense-in-depth, but it's totally unacceptable to rely on containers for "real" security, e.g. isolation between tenants.

Reply on news.ycombinator.com