Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190211130520.xwi6vpay3sc56pza@yavin>
Date: Tue, 12 Feb 2019 00:05:20 +1100
From: Aleksa Sarai <cyphar@...har.com>
To: oss-security@...ts.openwall.com
Cc: dev@...ncontainers.org, security-announce@...ncontainers.org
Subject: CVE-2019-5736: runc container breakout (all versions)

[[        Patch CRD: 2019-02-11 15:00 CET ]]
[[ Exploit Code CRD: 2019-02-18 15:00 CET ]]

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/0a8e4117e7f715d5fbeef398405813ce8e88558b
[2]: https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d
[3]: https://github.com/opencontainers/org/blob/master/security.md

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

View attachment "0001-nsenter-clone-proc-self-exe-to-avoid-exposing-host-b.patch" of type "text/x-patch" (7643 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.