Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rkt enter lacks isolation features #3998

Open
YuvalAvra opened this issue May 30, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@YuvalAvra
Copy link

commented May 30, 2019

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

This comment has been minimized.

Copy link

commented Jun 1, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 2, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.