Breaking Out of Docker via RunC

(twistlock.com)

116 points | by zelivans 1861 days ago

5 comments

  • simosx 1861 days ago
    A post by Christian Brauner (LXC/LXD developer) on how LXC and LXD are affected. In summary, unprivileged containers (as found in LXD) are not affected.

    https://brauner.github.io/2019/02/12/privileged-containers.h...

  • helper 1861 days ago
    This is a really great exploration of this vulnerability.

    It makes me sad that lxc doesn't get more love. LXC has had unprivileged containers as its default for 5+ years now. Its a really solid tool set that has mostly been passed over for lack of marketing.

    • barbecue_sauce 1861 days ago
      The reason Docker gets so much attention is its container image repository infrastructure. I'm sure LXC has something similar, but Docker's is built-in and has almost anything you can think of. (Of course, this presents other security/trust issues).
    • bboreham 1861 days ago
      Need to be careful that Docker and LXC both default to unprivileged, however they use the term to mean different things.

      If you say “don’t run your containers as root on the host”, this matches the issue better.

  • yutghgh 1861 days ago
    This is very interesting, because most docker break outs I see are exploits in the linux kernel, but this is one of the few in the containerization components themselves (first one I remember in runC).
    • cpuguy83 1861 days ago
      Definitely not the first. There was one with leaking file descriptors which weren't opened with O_CLOEXEC.

      Another with ptrace (fixed by making the process non-dumpable).

  • amerine 1861 days ago
    Are those diagrams generated via something or did you create it in an app?
  • awilddocker 1861 days ago
    why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
    • cyphar 1861 days ago
      Allowing your users to run something as root inside a container should violate a security audit. And yes, Docker is almost irresponsible to continue defaulting to root.

      But containers themselves should not -- there are plenty of security benefits to using containers. There is no real difference between an LXC container and a runc container besides the fact that Docker defaults to running thing as root and without user namespaces. That is obviously a bad decision, but it's not an indictment of containers as a concept.

    • MotiveMe 1861 days ago
      We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.
      • otterley 1861 days ago
        AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.
        • jen20 1861 days ago
          Something I've been wondering for a while (and you may be placed to answer): is firecracker part of the isolation story for Fargate - or is it regular EC2 instances?
      • cyphar 1861 days ago
        If you use user namespaces and don't run as host root, they provide a clear security value (unless your alternative is that you use user namespaces in your program, at which point you are making your own container runtime). Docker's (and LXC's) default seccomp profile has blocked something like 95% of kernel 0days since they were added, for instance.
    • yutghgh 1861 days ago
      Because the abstractions are good and the implementation gets better over time as with any other software. Obviously truly sensitive data should be handled on separate physical nodes (defense in depth).
    • praptak 1861 days ago
      I am not sure why this got downvoted, it is a valid question which got an informative response.
      • dasil003 1861 days ago
        Because it's a hyperbolic rhetorical question. Security teams don't just unilaterally ban things without context, especially things that provide significant business value. It's about threat modeling and what the risk is in practice for the company and use case in question.
        • lkschubert8 1861 days ago
          Good security teams*. I have definitely experienced overzealous bad security.