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

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

@yuvalavra

Description

@yuvalavra

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions