Language Selection

English French German Italian Portuguese Spanish

Security: Apple, 'Cloud', Containers and More FUD

Filed under
Security

Container flaw: original message about the security patch

  • CVE-2019-5736: runc container breakout

    Hello,

    I am one of the maintainers of runc (the underlying container runtime
    underneath Docker, cri-o, containerd, Kubernetes, and so on). We
    recently had a vulnerability reported which we have verified and have a
    patch for.

    The researchers who found this vulnerability are:
    * Adam Iwaniuk
    * Borys Popławski

    In addition, Aleksa Sarai (me) discovered that LXC was also vulnerable
    to a more convoluted version of this flaw.

    == OVERVIEW ==

    The vulnerability 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 within a container in either of these
    contexts:

    * Creating a new container using an attacker-controlled image.
    * Attaching (docker exec) into an existing container which the
    attacker had previous write access to.

    This vulnerability is *not* blocked by the default AppArmor policy, nor
    by the default SELinux policy on Fedora[++] (because container processes
    appear to be running as container_runtime_t). However, it *is* blocked
    through correct use of user namespaces (where the host root is not
    mapped into the container's user namespace).

    Our CVSSv3 vector is (with a score of 7.2):

    AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

    The assigned CVE for this issue is CVE-2019-5736.

    [++]: This is only the case for the "moby-engine" package on Fedora. The
    "docker" package as well as podman are protected against this
    exploit because they run container processes as container_t.

    == PATCHES ==

    I have attached the relevant patch which fixes this issue. This patch is
    based on HEAD, but the code in libcontainer/nsenter/ changes so
    infrequently that it should apply cleanly to any old version of the runc
    codebase you are dealing with.

    Please note that the patch I have pushed to runc master[1] is a modified
    version of this patch -- even though it is functionally identical
    (though we would recommend using the upstream one if you haven't patched
    using the attached one already).

    == NON-ESSENTIAL EXPLOIT CODE ==

    Several vendors have asked for exploit code to ensure that the patches
    actually solve the issue. Due to the severity of the issue (especially
    for public cloud vendors), we decided to provide the attached exploit
    code. This exploit code was written by me, and is more generic than the
    original exploit code provided by the researchers and works against LXC
    (it could likely be used on other vulnerable runtimes with no
    significant modification). Details on how to use the exploit code are
    provided in the README.

    As per OpenWall rules, this exploit code will be published *publicly* 7
    days after the CRD (which is 2019-02-18). *If you have a container
    runtime, please verify that you are not vulnerable to this issue
    beforehand.*

    == IMPACT ON OTHER PROJECTS ==

    It should be noted that upon further investigation I've discovered that
    LXC has a similar vulnerability, and they have also pushed a similar
    patch[2] which we co-developed. LXC is a bit harder to exploit, but the
    same fundamental flaw exists.

    After some discussion with the systemd-nspawn folks, it appears that
    they aren't vulnerable (because their method of attaching to a container
    uses a different method to LXC and runc).

    I have been contacted by folks from Apache Mesos who said they were also
    vulnerable (I believe just using the exploit code that will be
    provided). It is quite likely that most container runtimes are
    vulnerable to this flaw, unless they took very strange mitigations
    before-hand.

    == OTHER NEWS ==

    We have set up an announcement list for future security vulnerabilities,
    and you can see the process for joining here[3] (it's based on the
    Kubernetes security-announce mailing list). Please join if you
    distribute any container runtimes that depend on runc (or other OCI
    projects).

    [1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f...
    [2]: https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49ba...
    [3]: https://github.com/opencontainers/org/blob/master/securit...

    --
    Aleksa Sarai

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Mozilla on Nuisance Videos and Servo Progress

Programming and HowTos: The Leftovers

Gustavo Silva: Disco Dingo Thoughts

Those already around me know I love Linux and my favourite linux distribuition is Ubuntu. One of the reasons Ubuntu is my favourite is how simple and compatible it is with pretty much all devices I have tried installing. Except my laptop, but that’s due to the graphics card. But hey, I fondly received the news that now we can select the option to automatically set nomodeset and other convenient tools when running the setup. For me, this means a major win. I previously had to set nomodeset manually and after installation I had to immediately modifiy some options in the grub’s defaults (namely set the acpi=force) but now, with this new option, the installation process which was already smooth, become (melted) butter. Thank you, honestly, person who remembered to include this option. This seems like a feature that will stick to Ubuntu 20.04, so I’m happy to now a LTS version will become even simpler to install too, so that’s great. The UI and custom-Gnome experience has been improved as well, in this custom flavour of Gnome. We now have a few more options for customization, including dark options of the themes but I am definitely pleased to say that the Gnome shell, in Ubuntu 19.04, really looks great. Read more

5 of the Best Linux Desktops for Touchscreen Monitors in 2019

The concept of using Linux on a touchscreen monitor or two-in-one computer has come a long way. Touchscreen support is now built into the Linux kernel, so theoretically any Linux distribution should run with a touchscreen. That said, not every distribution will be easy to use on a touchscreen, and this comes down to the desktop. For example, using a tiling window manager like Awesome or i3 isn’t going to do you much good on a touchscreen. Choose the right desktop (more precisely, desktop environment), and you’ll have a much better time using Linux with a touchscreen. Read more