You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 24, 2020. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
The
rkt run
andrkt 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.
--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 theenterexec
binary through/proc/${enterexec-pid}/exe
. This will currently fail though because normal processes inside the container have fewer capabilities than processes spawned byrkt 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.The text was updated successfully, but these errors were encountered: