[HN Gopher] Leaky Vessels flaws allow hackers to escape Docker, ...
___________________________________________________________________
Leaky Vessels flaws allow hackers to escape Docker, runc containers
Author : el_duderino
Score : 52 points
Date : 2024-02-04 15:32 UTC (7 hours ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| j16sdiz wrote:
| I have seen this for ages and thought it was some design
| limitation. Didn't attempt to report it as vulneribility ...
| rdegges wrote:
| 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.
| px43 wrote:
| 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.
| nyrikki wrote:
| 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.
| rdegges wrote:
| 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.
| flaminHotSpeedo wrote:
| 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
| mrweasel wrote:
| 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.
| flaminHotSpeedo wrote:
| 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)
| nyrikki wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| Why is it all or nothing? It's absolutely a security control.
| WhatIsDukkha wrote:
| 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.
| fbdab103 wrote:
| 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
| mrweasel wrote:
| 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.
| flaminHotSpeedo wrote:
| 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.
| tptacek wrote:
| 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.
| hipadev23 wrote:
| 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.
| flaminHotSpeedo wrote:
| Definitely not the minority, anyone who needs secure
| isolation for a container should be wrapping it in a single
| tenant VM
| throwoutway wrote:
| Firecracker has often been recommended (here on HN and
| elsewhere) for a VM-for container-execution model :
| https://github.com/firecracker-microvm/firecracker
| tptacek wrote:
| 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
| akaike wrote:
| That's why it's better to run a docker container inside a micro
| vm I guess.
| Wool2662 wrote:
| 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.
___________________________________________________________________
(page generated 2024-02-04 23:01 UTC)