Page 2 of 10 results (0.018 seconds)

CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0

containerd is an open source container runtime with an emphasis on simplicity, robustness and portability. A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. • https://cert-portal.siemens.com/productcert/pdf/ssa-222547.pdf https://github.com/containerd/containerd/commit/5b46e404f6b9f661a205e28d59c982d3634148f8 https://github.com/containerd/containerd/security/advisories/GHSA-c2h3-6mxw-7mvq https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/B5Q6G6I4W5COQE25QMC7FJY3I3PAYFBB https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZNFADTCHHYWVM6W4NJ6CB4FNFM2VMBIB https://security.gentoo.org/glsa/202401-31 https://www.debian • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •

CVSS: 6.8EPSS: 0%CPEs: 3EXPL: 0

containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where pulling and extracting a specially-crafted container image can result in Unix file permission changes for existing files in the host’s filesystem. Changes to file permissions can deny access to the expected owner of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process. This bug has been fixed in containerd 1.5.4 and 1.4.8. • https://github.com/containerd/containerd/releases/tag/v1.4.8 https://github.com/containerd/containerd/releases/tag/v1.5.4 https://github.com/containerd/containerd/security/advisories/GHSA-c72p-9xmj-rx3w https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/DDMNDPJJTP3J5GOEDB66F6MGXUTRG3Y3 https://security.gentoo.org/glsa/202401-31 https://access.redhat.com/security/cve/CVE-2021-32760 https://bugzilla.redhat.com/show_bug.cgi?id=1982681 • CWE-281: Improper Preservation of Permissions CWE-668: Exposure of Resource to Wrong Sphere CWE-732: Incorrect Permission Assignment for Critical Resource •

CVSS: 6.3EPSS: 0%CPEs: 4EXPL: 0

In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers launched through containerd's CRI implementation (through Kubernetes, crictl, or any other pod/container client that uses the containerd CRI service) that share the same image may receive incorrect environment variables, including values that are defined for other containers. If the affected containers have different security contexts, this may allow sensitive information to be unintentionally shared. If you are not using containerd's CRI implementation (through one of the mechanisms described above), you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image which have different environment variables, you are not vulnerable to this issue. If you are not launching multiple containers or Kubernetes pods from the same image in rapid succession, you have reduced likelihood of being vulnerable to this issue This vulnerability has been fixed in containerd 1.3.10 and containerd 1.4.4. • https://github.com/containerd/containerd/commit/05f951a3781f4f2c1911b05e61c160e9c30eaa8e https://github.com/containerd/containerd/releases/tag/v1.3.10 https://github.com/containerd/containerd/releases/tag/v1.4.4 https://github.com/containerd/containerd/security/advisories/GHSA-6g2q-w5j3-fwh4 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KUE2Z2ZUWBHRU36ZGBD2YSJCYB6ELPXE https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIBPKSX5IOWPM3ZPFB3JVLXWDHSZTTWT ht • CWE-668: Exposure of Resource to Wrong Sphere •

CVSS: 8.8EPSS: 0%CPEs: 4EXPL: 0

containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. • https://github.com/containerd/containerd/commit/4a4bb851f5da563ff6e68a83dc837c7699c469ad https://github.com/containerd/containerd/releases/tag/v1.4.3 https://github.com/containerd/containerd/security/advisories/GHSA-36xw-fx78-c5r4 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LNKXLOLZWO5FMAPX63ZL7JNKTNNT5NQD https://security.gentoo.org/glsa/202105-33 https://www.debian.org/security/2021/dsa-4865 https://access.redhat.com/security/cve/CVE-2020-15257 https://bugzilla.redh • CWE-269: Improper Privilege Management CWE-669: Incorrect Resource Transfer Between Spheres •

CVSS: 6.1EPSS: 0%CPEs: 13EXPL: 0

In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. • https://github.com/containerd/containerd/releases/tag/v1.2.14 https://github.com/containerd/containerd/security/advisories/GHSA-742w-89gc-8m9c https://usn.ubuntu.com/4589-1 https://usn.ubuntu.com/4589-2 https://www.debian.org/security/2021/dsa-4865 https://access.redhat.com/security/cve/CVE-2020-15157 https://bugzilla.redhat.com/show_bug.cgi?id=1888248 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-522: Insufficiently Protected Credentials •