Skip to content
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.

rkt can be tricked into executing helper binaries inside pods #3999

Open
yuvalavra opened this issue May 30, 2019 · 0 comments
Open

rkt can be tricked into executing helper binaries inside pods #3999

yuvalavra opened this issue May 30, 2019 · 0 comments

Comments

@yuvalavra
Copy link

The rkt run and rkt enter commands in the default systemd/nspawn flavor the can be tricked into executing helper binaries inside containers. Those helper binaries can then be overwritten by an attacker inside the container through /proc/{helper-binary-pid}/exe. Since several of those binaries are executed by rkt as root in the context of the host, an attacker from inside the container can use this flaw to compromise the host.

This issue was reported to RedHat & CoreOS according to the instructions here. It is reported here as a possible security-in-depth enhancement according to the course of action suggested by RedHat.

rkt run

The rkt run command can be tricked by a malicious ACI or OCI image into executing rkt helper binaries inside the container. This can be done by specifying the entry point of an image to /proc/1/root/${helper-binary} (e.g. /proc/1/root/gc). This binary can then be overwritten from inside the container through /proc/${helper-binary-pid}/exe.

This is obviously not ideal, but rkt do explicitly recommends running only trusted and signed images.

  • In the case of ACI images, the image format itself allows specifying security options. These options, called isolators, include controlling the capabilities given to and seccomp filtering applied to the image upon running as a container. Therefore it might be possible to create a malicious image that compromises the host without exploiting this issue.
  • In the case of OCI images, fetching them requires using an insecure configuration (--insecure-options=image).

rkt enter

The rkt enter command helper binary, enterexec, can be tricked into executing itself inside the container by asking it to run /proc/self/exe. Other processes inside the container can then try and overwrite the enterexec binary through /proc/${enterexec-pid}/exe. This will currently fail though because normal processes inside the container have fewer capabilities than processes spawned by rkt enter (as explained in #3998). Therefore, and according to ptrace access mode rules (specifically rule 5b, search for the keyword ‘security_ptrace_access_check’), normal processes inside the container aren’t able to access /proc/${enterexec-pid}/exe.

If #3998 is fixed and the capabilities of processes spawned by rkt enter are limited to match those of normal processes in the container, this attack becomes possible.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant