#kubernetes

runc versions 1.1.11 and below, as used by containerization technologies such as Docker engine and Kubernetes, are vulnerable to an arbitrary file write vulnerability. Due to a file descriptor leak it is possible to mount the host file system with the permissions of runc (typically root). Successfully tested on Ubuntu 22.04 with runc 1.1.7-0ubuntu1~22.04.1 using Docker build.

When it comes to open-source innovation, Red Hat is committed to pushing technological boundaries and enhancing the capabilities of cutting-edge solutions. As we look back at 2023, we’ll discuss Red Hat's role in advancing Extended Berkeley Packet Filter (eBPF) technology, from collaborative contributions to the Linux kernel to strategic implementations within Red Hat's portfolio, and explore the intersection of innovation, performance, security capabilities and networking within the evolving landscape of eBPF.Kernel upstream collaborationsRed Hat engineers actively collaborated with the Lin

### Impact Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626. ### Patches `runc` runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4. ### Workarounds Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability. ### References * [CVE-2024-21626](https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv) * [Vulnerability: runc process.cwd and leaked fds container breakout](https://snyk.io/blog/cve-2024-21626-runc-process-cwd-container-breakout/)

Red Hat Security Advisory 2024-0484-03 - Red Hat OpenShift Container Platform release 4.13.31 is now available with updates to packages and images that fix several bugs and add enhancements.

Cloudflare has revealed that it was the target of a likely nation-state attack in which the threat actor leveraged stolen credentials to gain unauthorized access to its Atlassian server and ultimately access some documentation and a limited amount of source code. The intrusion, which took place between November 14 and 24, 2023, and detected on November 23, was carried out "with the goal of

Red Hat Security Advisory 2024-0489-03 - Red Hat OpenShift Container Platform release 4.12.48 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a denial of service vulnerability.

Red Hat Security Advisory 2024-0485-03 - Red Hat OpenShift Container Platform release 4.12.48 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include a cross site scripting vulnerability.

Peer-pods extends Red Hat OpenShift sandboxed containers to run on any environment without requiring bare-metal servers or nested virtualization support. It does this by extending Kata containers runtime (OpenShift sandboxed containers is built on Kata containers) to handle virtual machine (VM) lifecycle management using cloud provider APIs (AWS, Azure and others) or a third-party hypervisor API such as VMware vSphere. The peer-pods solution is also the foundation for confidential containers on OpenShift.Currently, there is no support for Container Storage Interface (CSI) persistent volumes fo

## Impact 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 ## Patches This vulnerability has been fixed in containerd 1.3.10 and containerd 1.4.4. Users...

### 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 ...