Bug 1663068 - runc: not using pivot_root allows mounting of /proc [NEEDINFO]
Summary: runc: not using pivot_root allows mounting of /proc
Keywords:
Status: NEW
Alias: None
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1663070 1665769 1665770 1667622 1667626
Blocks: 1663066
TreeView+ depends on / blocked
 
Reported: 2019-01-03 02:27 UTC by Jason Shepherd
Modified: 2019-09-29 15:04 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Not using pivot_root(2) leaves the host /proc around in the mount namespace so that it is possible to mount another /proc without any other submount, even if /proc in the container is not fully visible. This flaw allows an attacker to read and modify some parts of the Linux kernel memory.
Clone Of:
Environment:
Last Closed:
jshepherd: needinfo? (dwalsh)


Attachments (Terms of Use)

Description Jason Shepherd 2019-01-03 02:27:19 UTC
Not using pivot_root(2) leaves the host /proc around in the mount namespace so that it is possible to mount another /proc without any other submount, even if /proc in the container is not fully visible. This flaw allows an attacker to read and modify some parts of the Linux kernel memory.

Comment 1 Jason Shepherd 2019-01-03 02:27:26 UTC
Acknowledgments:

Name: the Kubernetes Product Security Team
Upstream: Akihiro Suda

Comment 5 Daniel Walsh 2019-01-03 14:23:39 UTC
Can't access the link?  Could you tell me what SELinux label is running when you break out?  `id -Z`

Just curious about whether SELinux blocks the exploit, or at least confines it.

Comment 6 Jason Shepherd 2019-01-03 23:39:33 UTC
I requested access by granted to the runc directory of SRTVULNS repo, but it might take a while to be applied.

In the meantime, I see that I don't have any SELinux context applied:

$ cat /etc/redhat-release 
Fedora release 29 (Twenty Nine)
$ runc --version
runc version 1.0.0-rc6+dev
commit: ead425507b6ba28278ef71ad06582df97f2d5b5f
spec: 1.0.1-dev

$ docker create --name BZ1663068 fedora sh
$ docker export BZ1663068 > BZ1663068.tar
$ docker rm -f BZ1663068

$ mkdir rootfs
$ tar -xf BZ1663068.tar -C rootfs

$ runc spec --rootless
$ runc --root /tmp/runc run --no-pivot BZ1663068
sh-4.4# id -Z
id: --context (-Z) works only on an SELinux-enabled kernel

My kernel does have SELinux-enabled, however I'm not sure if runc was compiled with SELinux enabled or not.

Comment 7 Daniel Walsh 2019-01-04 00:56:56 UTC
Sorry id -Z might be lying to you.

Inside the container do:
cat /proc/self/current/attr

Outside do getenforce, to make sure SELinux is enabled.

Comment 8 Jason Shepherd 2019-01-10 00:15:58 UTC
Seems it's current with 'unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023'

[root@runc /]# cat /proc/self/attr/current
unconfined_u:system_r:container_runtime_t:s0-s0:c0.c1023
[root@runc /]# exit
logout
sh-4.4# exit
exit
[jshepher@localhost BZ1663068]$ getenforce
Enforcing

Comment 10 Jason Shepherd 2019-01-10 00:27:19 UTC
Statement:

CRI-O defaults to 'no_pivot' [1] being 'false', so it's not affected by this issue. Users should avoid setting 'no_pivot' to 'true' to prevent this flaw when using a vulnerable versions of runc with CRI-O.

Podman is not affected by this issue as it doesn't use 'runc run --no-pivot'.

[1] https://github.com/kubernetes-sigs/cri-o/blob/master/docs/crio.conf.5.md

Comment 11 Daniel Walsh 2019-01-10 12:45:23 UTC
Jason, if you run runc with a spec file that does not set a confined SELinux label or any at all, it runs as container_runtime_t.

If this was run by podman, CRI-O, Buildah or Docker, by default it would run as container_t, and escape would probably be prevented
or at least controlled.  Since container_t is only able to read /usr and some of /etc, and only able to write to container_file_t.

Of course if you run on an SELinux disabled machine or permissive, or you run your container engine with SELinux disabled then
the escalation would not be prevented by SELinux.

Comment 12 Jason Shepherd 2019-01-11 04:02:10 UTC
Is is possible to make use of the '--no-pivot' option of runc when launching it via docker in RHEL? Trying to figure out if 'docker' on RHEL7 would be affected or not if running without SELinux enforcing.

Comment 13 Jason Shepherd 2019-01-11 04:02:12 UTC
Mitigation:

With SELinux in enforcing mode, and a runc spec file that set a confined SELinux label the container would run with the container_t label and the escape would be prevented. Podman, CRI-O, Buildah or Docker, by default it would run as container_t, and escape would be prevented, since container_t is only able to read /usr and some of /etc, and only able to write to files labelled container_file_t.

Comment 14 Jason Shepherd 2019-01-13 22:58:29 UTC
Upstream Git Pull Request: https://github.com/opencontainers/runc/pull/1962

Comment 15 Jason Shepherd 2019-01-13 22:59:44 UTC
Created runc tracking bugs for this issue:

Affects: fedora-all [bug 1665769]

Comment 17 Sam Fowler 2019-01-29 03:31:56 UTC
Upstream pointed out that run's `--no-pivot` flag is already known to be insecure as it allows access to the host filesystem from the container. Thus, this particular bug does not warrant a CVE.


Note You need to log in before you can comment on or make changes to this bug.