CVE-2021-43816
published 2022-01-05CVE-2021-43816: containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since…
PriorityP350critical9.1CVSS 3.1
AVNACLPRHUINSCCHIHAH
EPSS
1.69%
74.2th percentile
containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files. This issue has been resolved in version 1.5.9. Users are advised to upgrade as soon as possible.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| containerd | containerd | — | — |
| containerd | containerd | >= 0 < 1.5.9~ds1-1 | 1.5.9~ds1-1 |
| containerd | containerd | >= 0 < 1.5.9~ds1-1 | 1.5.9~ds1-1 |
| containerd | containerd | >= 0 < 1.5.9~ds1-1 | 1.5.9~ds1-1 |
| debian | containerd | < containerd 1.5.9~ds1-1 (bookworm) | containerd 1.5.9~ds1-1 (bookworm) |
| fedoraproject | fedora | — | — |
| fedoraproject | fedora | — | — |
| github.com | containerd_containerd | >= 1.5.0 < 1.5.9 | 1.5.9 |
| linuxfoundation | containerd | — | — |
| linuxfoundation | containerd | >= 1.5.1 < 1.5.9 | 1.5.9 |
CVSS provenance
nvdv3.19.1CRITICALCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
nvdv2.06.0MEDIUMAV:N/AC:M/Au:S/C:P/I:P/A:P
osv9.1CRITICAL
vendor_debian8.0HIGH
vendor_redhat8.0HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
containerd: Unprivileged pod may bind mount any privileged regular file on disk
vendor_redhat·2022-01-05·CVSS 8.0
CVE-2021-43816 [HIGH] CWE-281 containerd: Unprivileged pod may bind mount any privileged regular file on disk
containerd: Unprivileged pod may bind mount any privileged regular file on disk
containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access
Debian
CVE-2021-43816: containerd - containerd is an open source container runtime. On installations using SELinux, ...
vendor_debian·2021·CVSS 8.0
CVE-2021-43816 [HIGH] CVE-2021-43816: containerd - containerd is an open source container runtime. On installations using SELinux, ...
containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files. This issue has been resolved in version 1.5.9. Users are
OSV
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux in github.com/containerd/containerd
osv·2024-08-21
CVE-2021-43816 Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux in github.com/containerd/containerd
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux in github.com/containerd/containerd
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux in github.com/containerd/containerd
OSV
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
osv·2022-01-06
CVE-2021-43816 [HIGH] Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
### Impact
Containers launched through containerd’s CRI implementation on Linux systems which use the SELinux security module and containerd versions since v1.5.0 can cause arbitrary files and directories on the host to be relabeled to match the container process label through the use of specially-configured bind mounts in a hostPath volume. This relabeling elevates permissions for the container, granting full read/write access over the affected files and directories. Kubernetes and crictl can both be configured to use containerd’s CRI implementation.
If you are not using containerd’s CRI implementation (through one of the mechanisms described above), you are not affected by this issue.
### Patches
This bug
GHSA
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
ghsa·2022-01-06
CVE-2021-43816 [HIGH] CWE-281 Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
Unprivileged pod using `hostPath` can side-step active LSM when it is SELinux
### Impact
Containers launched through containerd’s CRI implementation on Linux systems which use the SELinux security module and containerd versions since v1.5.0 can cause arbitrary files and directories on the host to be relabeled to match the container process label through the use of specially-configured bind mounts in a hostPath volume. This relabeling elevates permissions for the container, granting full read/write access over the affected files and directories. Kubernetes and crictl can both be configured to use containerd’s CRI implementation.
If you are not using containerd’s CRI implementation (through one of the mechanisms described above), you are not affected by this issue.
### Patches
This bug
OSV
CVE-2021-43816: containerd is an open source container runtime
osv·2022-01-05·CVSS 9.1
CVE-2021-43816 [CRITICAL] CVE-2021-43816: containerd is an open source container runtime
containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files. This issue has been resolved in version 1.5.9. Users are
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://github.com/containerd/containerd/commit/a731039238c62be081eb8c31525b988415745eeahttps://github.com/containerd/containerd/issues/6194https://github.com/containerd/containerd/security/advisories/GHSA-mvff-h3cj-wj9chttps://github.com/dweomer/containerd/commit/f7f08f0e34fb97392b0d382e58916d6865100299https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GD5GH7NMK5VJMA2Y5CYB5O5GTPYMWMLX/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MPDIZMI7ZPERSZE2XO265UCK5IWM7CID/https://github.com/containerd/containerd/commit/a731039238c62be081eb8c31525b988415745eeahttps://github.com/containerd/containerd/issues/6194https://github.com/containerd/containerd/security/advisories/GHSA-mvff-h3cj-wj9chttps://github.com/dweomer/containerd/commit/f7f08f0e34fb97392b0d382e58916d6865100299https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GD5GH7NMK5VJMA2Y5CYB5O5GTPYMWMLX/https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MPDIZMI7ZPERSZE2XO265UCK5IWM7CID/
2022-01-05
Published