Search for packages
| purl | pkg:deb/debian/runc@0.1.1%2Bdfsg1-2%2Bdeb9u1 |
| Next non-vulnerable version | 1.0.3+ds1-1 |
| Latest non-vulnerable version | 1.3.3+ds1-2 |
| Risk | 10.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-3m4n-58pj-mkeb
Aliases: CVE-2022-29162 GHSA-f3fp-gc8g-vw66 |
Multiple vulnerabilities have been discovered in runc, the worst of which could lead to privilege escalation. |
Affected by 5 other vulnerabilities. |
|
VCID-3yvf-q4uj-dbdh
Aliases: CVE-2021-43784 GHSA-v95c-p5hm-xq8f |
Overflow in netlink bytemsg length field allows attacker to override netlink-based container configuration in RunC ### Impact In runc, [netlink](https://www.man7.org/linux/man-pages/man7/netlink.7.html) is used internally as a serialization system for specifying the relevant container configuration to the C portion of our code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration. This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces. Prior to 9c444070ec7bb83995dbc0185da68284da71c554, in practice it was fairly difficult to specify an arbitrary-length netlink message with most container runtimes. The only user-controlled byte array was the namespace paths attributes which can be specified in runc's `config.json`, but as far as we can tell no container runtime gives raw access to that configuration setting -- and having raw access to that setting **would allow the attacker to disable namespace protections entirely anyway** (setting them to `/proc/1/ns/...` for instance). In addition, each namespace path is limited to 4096 bytes (with only 7 namespaces supported by runc at the moment) meaning that even with custom namespace paths it appears an attacker still cannot shove enough bytes into the netlink bytemsg in order to overflow the uint16 counter. However, out of an abundance of caution (given how old this bug is) we decided to treat it as a potentially exploitable vulnerability with a low severity. After 9c444070ec7bb83995dbc0185da68284da71c554 (which was not present in any release of runc prior to the discovery of this bug), all mount paths are included as a giant netlink message which means that this bug becomes significantly more exploitable in more reasonable threat scenarios. The main users impacted are those who allow untrusted images with untrusted configurations to run on their machines (such as with shared cloud infrastructure), though as mentioned above it appears this bug was not practically exploitable on any released version of runc to date. ### Patches The patch for this is d72d057ba794164c3cce9451a00b72a78b25e1ae and runc 1.0.3 was released with this bug fixed. ### Workarounds To the extent this is exploitable, disallowing untrusted namespace paths in container configuration should eliminate all practical ways of exploiting this bug. It should be noted that untrusted namespace paths would allow the attacker to disable namespace protections entirely even in the absence of this bug. ### References * commit d72d057ba794 ("runc init: avoid netlink message length overflows") * https://bugs.chromium.org/p/project-zero/issues/detail?id=2241 ### Credits Thanks to Felix Wilhelm from Google Project Zero for discovering and reporting this vulnerability. In particular, the fact they found this vulnerability so quickly, before we made a 1.1 release of runc (which would've been vulnerable) was quite impressive. ### For more information If you have any questions or comments about this advisory: * Open an issue in [our repo](https://github.com/opencontainers/runc) |
Affected by 4 other vulnerabilities. |
|
VCID-7juj-78y7-g7b6
Aliases: CVE-2019-5736 |
Containment Errors (Container Errors) runc allows attackers to overwrite the host runc binary (and consequently obtain host root access) by leveraging the ability to execute a command as root within one of these types of containers: (1) a new container with an attacker-controlled image, or (2) an existing container, to which the attacker previously had write access, that can be attached with docker exec. This occurs because of file-descriptor mishandling, related to `/proc/self/exe`. |
Affected by 9 other vulnerabilities. |
|
VCID-997v-f2ds-e3e4
Aliases: CVE-2019-19921 GHSA-fh74-hm69-rqjw |
Multiple vulnerabilities have been discovered in runC, the worst of which may lead to privilege escalation. |
Affected by 6 other vulnerabilities. |
|
VCID-9mdg-3961-cybf
Aliases: CVE-2021-30465 GHSA-c3xm-pvg7-gh7r |
mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs ### Summary runc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby an attacker can request a seemingly-innocuous container configuration that actually results in the host filesystem being bind-mounted into the container (allowing for a container escape). CVE-2021-30465 has been assigned for this issue. An attacker must have the ability to start containers using some kind of custom volume configuration, and while recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of damage an attacker could do, they do not block this attack outright. We have a reproducer using Kubernetes (and the below description mentions Kubernetes-specific paths), but this is not a Kubernetes-specific issue. The now-released [runc v1.0.0-rc95][release] contains a fix for this issue, we recommend users update as soon as possible. [release]: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95 ### Details In circumstances where a container is being started, and runc is mounting inside a volume shared with another container (which is conducting a symlink-exchange attack), runc can be tricked into mounting outside of the container rootfs by swapping the target of a mount with a symlink due to a time-of-check-to-time-of-use (TOCTTOU) flaw. This is fairly similar in style to previous TOCTTOU attacks (and is a problem we are working on solving with libpathrs). However, this alone is not useful because this happens inside a mount namespace with `MS_SLAVE` propagation applied to `/` (meaning that the mount doesn't appear on the host -- it's only a "host-side mount" inside the container's namespace). To exploit this, you must have additional mount entries in the configuration that use some subpath of the mounted-over host path as a source for a subsequent mount. However, it turns out with some container orchestrators (such as Kubernetes -- though it is very likely that other downstream users of runc could have similar behaviour be accessible to untrusted users), the existence of additional volume management infrastructure allows this attack to be applied to gain access to the host filesystem without requiring the attacker to have completely arbitrary control over container configuration. In the case of Kubernetes, this is exploitable by creating a symlink in a volume to the top-level (well-known) directory where volumes are sourced from (for instance, `/var/lib/kubelet/pods/$MY_POD_UID/volumes/kubernetes.io~empty-dir`), and then using that symlink as the target of a mount. The source of the mount is an attacker controlled directory, and thus the source directory from which subsequent mounts will occur is an attacker-controlled directory. Thus the attacker can first place a symlink to `/` in their malicious source directory with the name of a volume, and a subsequent mount in the container will bind-mount `/` into the container. Applying this attack requires the attacker to start containers with a slightly peculiar volume configuration (though not explicitly malicious-looking such as bind-mounting `/` into the container explicitly), and be able to run malicious code in a container that shares volumes with said volume configuration. It helps the attacker if the host paths used for volume management are well known, though this is not a hard requirement. ### Patches This has been patched in runc 1.0.0-rc95, and users should upgrade as soon as possible. The patch itself can be found [here](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f). ### Workarounds There are no known workarounds for this issue. However, users who enforce running containers with more confined security profiles (such as reduced capabilities, not running code as root in the container, user namespaces, AppArmor/SELinux, and seccomp) will restrict what an attacker can do in the case of a container breakout -- we recommend users make use of strict security profiles if possible (most notably user namespaces -- which can massively restrict the impact a container breakout can have on the host system). ### References * [commit](https://github.com/opencontainers/runc/commit/0ca91f44f1664da834bc61115a849b56d22f595f) * [seclists public disclosure](https://www.openwall.com/lists/oss-security/2021/05/19/2) ### Credit Thanks to Etienne Champetier for discovering and disclosing this vulnerability, to Noah Meyerhans for writing the first draft of this patch, and to Samuel Karp for testing it. ### For more information If you have any questions or comments about this advisory: * Open an issue in [our issue tracker](https://github.com/opencontainers/runc/issues). * Email us at <security@opencontainers.org>. |
Affected by 6 other vulnerabilities. |
|
VCID-jc1e-8tt4-xqdn
Aliases: CVE-2023-27561 GHSA-vpvm-3wq2-2wvm |
Opencontainers runc Incorrect Authorization vulnerability runc 1.0.0-rc95 through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to `libcontainer/rootfs_linux.go`. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a CVE-2019-19921 regression. |
Affected by 4 other vulnerabilities. |
|
VCID-seds-dzew-jyfs
Aliases: CVE-2023-28642 GHSA-g2j6-57v7-gm8c |
runc AppArmor bypass with symlinked /proc ### Impact It was found that AppArmor, and potentially SELinux, can be bypassed when `/proc` inside the container is symlinked with a specific mount configuration. ### Patches Fixed in runc v1.1.5, by prohibiting symlinked `/proc`: https://github.com/opencontainers/runc/pull/3785 This PR fixes CVE-2023-27561 as well. ### Workarounds Avoid using an untrusted container image. |
Affected by 4 other vulnerabilities. |
|
VCID-tsgr-5mwt-jkeh
Aliases: CVE-2024-21626 GHSA-xr7r-f8xq-vfvv |
runc vulnerable to container breakout through process.cwd trickery and leaked fds ### Impact In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable `runc exec` operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system. #### Attack 1: `process.cwd` "mis-configuration" In runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into `runc init`, including a handle to the host's `/sys/fs/cgroup` (this leak was added in v1.0.0-rc93). If the container was configured to have `process.cwd` set to `/proc/self/fd/7/` (the actual fd can change depending on file opening order in `runc`), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-`/` path a symlink to `/proc/self/fd/7/` and thus trick a user into starting a container whose binary has access to the host filesystem. Furthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container's mount namespace after calling `chdir(2)` (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after `pivot_root(2)`). The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity). Note that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using `ONBUILD` in the case of Docker). #### Attack 2: `runc exec` container breakout (This is a modification of attack 1, constructed to allow for a process inside a container to break out.) The same fd leak and lack of verification of the working directory in attack 1 also apply to `runc exec`. If a malicious process inside the container knows that some administrative process will call `runc exec` with the `--cwd` argument and a given path, in most cases they can replace that path with a symlink to `/proc/self/fd/7/`. Once the container process has executed the container binary, `PR_SET_DUMPABLE` protections no longer apply and the attacker can open `/proc/$exec_pid/cwd` to get access to the host filesystem. `runc exec` defaults to a cwd of `/` (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use `--cwd` and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the `execve` will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the `runc exec` is executing). The CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity). #### Attacks 3a and 3b: `process.args` host binary overwrite attack (These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using `execve` to bring a magic-link reference into the container.) Attacks 1 and 2 can be adapted to overwrite a host binary by using a path like `/proc/self/fd/7/../../../bin/bash` as the `process.args` binary argument, causing a host binary to be executed by a container process. The `/proc/$pid/exe` handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same `#!` trick can be used to avoid detection as an attacker). As the overwritten binary could be something like `/bin/bash`, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host. For the purposes of CVSS scoring: * Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute `/proc/self/fd/7/../../../bin/bash` and run a shell script that overwrites `/proc/self/exe`, overwriting the host copy of `/bin/bash`. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity). * Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible `runc exec` target binaries inside the container (such as `/bin/bash`) such that a host target binary is executed and then the container process opens `/proc/$pid/exe` to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity). As mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn't require a user to run a malicious image. ### Patches runc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied: * Checking that the working directory is actually inside the container by checking whether `os.Getwd` returns `ENOENT` (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks. * Close all internal runc file descriptors in the final stage of `runc init`, right before `execve`. This ensures that internal file descriptors cannot be used as an argument to `execve` and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don't close critical Go internal file descriptors. * Fixing the specific fd leaks that made these bug exploitable (mark `/sys/fs/cgroup` as `O_CLOEXEC` and backport a fix for some `*os.File` leaks). * In order to protect against future `runc init` file descriptor leaks, mark all non-stdio files as `O_CLOEXEC` before executing `runc init`. ### Other Runtimes We have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at [our patches](#Patches) and make sure they at least add a `getcwd() != ENOENT` check as well as consider whether `close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC)` before executing their equivalent of `runc init` is appropriate. * crun 1.12 does not leak any useful file descriptors into the `runc init`-equivalent process (so this attack is _not exploitable_ as far as we can tell), but no care is taken to make sure all non-stdio files are `O_CLOEXEC` and there is no check after `chdir(2)` to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to `crun` are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of `crun` can lead to these attacks becoming exploitable. * youki 0.3.1 does not leak any useful file descriptors into the `runc init`-equivalent process (so this attack is _not exploitable_ as far as we can tell) however this appears to be pure luck. `youki` does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets `pivot_root`'d into and so ends up as a in-root path thanks to `chroot_fs_refs`). In addition, no care is taken to make sure all non-stdio files are `O_CLOEXEC` and there is no check after `chdir(2)` to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to `youki` are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of `youki` can lead to these attacks becoming exploitable. * LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in `lxc-attach`. However, they don't seem to have any proactive protection against file descriptor leaks at the point of `chdir` such as using `close_range(...)` (they do have RAII-like `__do_fclose` closers but those don't necessarily stop all leaks in this context) nor do they have any check after `chdir(2)` to ensure the working directory is inside the container. Unfortunately it seems they cannot use `CLOSE_RANGE_CLOEXEC` because they don't need to re-exec themselves. ### Workarounds For attacks 1 and 2, only permit containers (and `runc exec`) to use a `process.cwd` of `/`. It is not possible for `/` to be replaced with a symlink (the path is resolved from within the container's mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink). For attacks 1 and 3a, only permit users to run trusted images. For attack 3b, there is no practical workaround other than never using `runc exec` because any binary you try to execute with `runc exec` could end up being a malicious binary target. ### See Also * https://www.cve.org/CVERecord?id=CVE-2024-21626 * https://github.com/opencontainers/runc/releases/tag/v1.1.12 * The runc 1.1.12 merge commit https://github.com/opencontainers/runc/commit/a9833ff391a71b30069a6c3f816db113379a4346, which contains the following security patches: * https://github.com/opencontainers/runc/commit/506552a88bd3455e80a9b3829568e94ec0160309 * https://github.com/opencontainers/runc/commit/0994249a5ec4e363bfcf9af58a87a722e9a3a31b * https://github.com/opencontainers/runc/commit/fbe3eed1e568a376f371d2ced1b4ac16b7d7adde * https://github.com/opencontainers/runc/commit/284ba3057e428f8d6c7afcc3b0ac752e525957df * https://github.com/opencontainers/runc/commit/b6633f48a8c970433737b9be5bfe4f25d58a5aa7 * https://github.com/opencontainers/runc/commit/683ad2ff3b01fb142ece7a8b3829de17150cf688 * https://github.com/opencontainers/runc/commit/e9665f4d606b64bf9c4652ab2510da368bfbd951 ### Credits Thanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using `runc exec` (attacks 2 and 3b). |
Affected by 4 other vulnerabilities. |
|
VCID-v2ys-xbn5-guh4
Aliases: CVE-2023-25809 GHSA-m8cg-xc2p-r3fc |
rootless: `/sys/fs/cgroup` is writable when cgroupns isn't unshared in runc ### Impact It was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) 2. or, when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare) A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users's cgroup hierarchies are not affected. ### Patches v1.1.5 (planned) ### Workarounds - Condition 1: Unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. - Condition 2 (very rare): add `/sys/fs/cgroup` to `maskedPaths` |
Affected by 4 other vulnerabilities. |
|
VCID-zex4-9xyf-6yf1
Aliases: CVE-2019-16884 GHSA-fgv8-vj5c-2ppq |
Multiple vulnerabilities have been discovered in runC, the worst of which may lead to privilege escalation. |
Affected by 6 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-165g-hgmx-nybk | Information Exposure in RunC RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container. |
CVE-2016-9962
GHSA-gp4j-w3vj-7299 |