A flaw was found in CRI-O. The fix for a previous vulnerability (CVE-2022-4318) was incorrect, allowing it to be bypassed. An attacker capable of setting environment variables on a container can inject a newline character into the HOME environment variable. This issue allows the addition of arbitrary lines into /etc/passwd by use of a specially crafted environment variable.

There's a vulnerability in the CRI-O application where when container is launched with securityContext.runAsUser specifying a non-existent user, CRI-O attempts to create the user, reading the container's entire /etc/passwd file into memory. If this file is excessively large, it can cause the a high memory consumption leading applications to be killed due to out-of-memory. As a result a denial-of-service can be achieved, possibly disrupting other pods and services running in the same host.

When running a container using the securityContext.runAsUser setting to specify which user the container should use to be ran, if the requested user is not present in the '/etc/passwd' file in the container image, cri-o tries to create the new user information. For that cri-o reads the passwd file into the memory all at once using os.ReadFile() function, if the read passwd file is too big it can lead to increased memory consumption, eventually resulting in a Denial of Service.

A flaw was found in CRI-O, the container runtime. Under a specific internal condition, CRI-O skips checking whether a container image's environment variable settings are properly formatted before using them. If an image contains a malformed environment variable, CRI-O crashes while trying to process it.

A flaw was found in CRI-O, the container runtime. Under a specific internal condition, CRI-O skips checking whether a container image's environment variable settings are properly formatted before using them. If an image contains a malformed environment variable, CRI-O crashes while trying to process it.

A flaw in the containers/common Go library, used by container runtimes such as Podman, Buildah, and CRI-O, allows a malicious container image to exploit the FIPS mode to bind mount arbitrary host directories into the container. The flaw arises from the MountsWithUIDGID() function, which attempts to mount a FIPS-related directory inside the container but does not properly verify the path. If the FIPS path is a symlink, it could point to arbitrary directories on the host, allowing an attacker to access sensitive host files.

Summary: Possible DOS in SPDY streaming code, used for attach, exec and port forwarding.

Requirements To Exploit: Access to the kubelet's endpoint (granted through nodes/proxy) or access to any of portforward, exec, or attach to pods. These all can be represented by the cluster roles

pods/portforward (create)

pods/exec (create)

pods/attach (create)

nodes/proxy (get/create)

Component Affected: Kubelet, CRI-O, kube-apiserver

Version Affected: Openshift 4.21.4 and below

Patch Available: yes

Version Fixed: none yet

Cvss: (Based on [https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]). Please note that only the Base Score Metrics are required by the incident response team.

Impact: Based on the https://access.redhat.com/security/updates/classification , what do you think would be the impact and why? This helps a lot the analyst to understand why such a report must be or not considered Moderate/Important or even Critical.

Steps To Reproduce: apply:

— apiVersion: v1 kind: ServiceAccount metadata: name: poc-sa-portforward namespace: default — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: Role metadata: name: poc-role-portforward namespace: default rules:

apiGroups: [""] resources: ["pods/portforward"] verbs: ["create"] — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: RoleBinding metadata: name: poc-rb-portforward namespace: default subjects:

kind: ServiceAccount name: poc-sa-portforward namespace: default roleRef: kind: Role name: poc-role-portforward apiGroup: rbac.authorization.k8s.io — apiVersion: v1 kind: Pod metadata: name: poc-target namespace: default spec: containers:

name: nginx image: nginx:alpine

set env:

export APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||')

export TOKEN=$(kubectl create token poc-sa-portforward)

export POD=poc-target

run attached pocportforward.py

Mitigation: disable the above cluster roles from untrusted users.

Embargo Reason: Coordination with three upstream communities: containerd, CRI-O, kubernetes

Original Report: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2

A vulnerability was found in CRI-O. A path traversal issue in the log management functions (UnMountPodLogs and LinkContainerLogs) may allow an attacker with permissions to create and delete Pods to unmount arbitrary host paths, leading to node-level denial of service by unmounting critical system directories.

The UnMountPodLogs and LinkContainerLogs functions in CRI-O do not properly validate the emptyDirVolName parameter, making them vulnerable to a path traversal attack. An attacker can exploit this to unmount arbitrary paths on the host system, potentially causing denial of service or compromising system integrity.