A vulnerability was found in CRI-O, where it can be requested to take a checkpoint archive of a container and later be asked to restore it. When it does that restoration, it attempts to restore the mounts from the restore archive instead of the pod request. As a result, the validations run on the pod spec, verifying that the pod has access to the mounts it specifies are not applicable …
A malicious container can affect the host by taking advantage of code cri-o added to show the container mounts on the host. A workload built from this Dockerfile: FROM docker.io/library/busybox as source RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc FROM scratch COPY –from=source /bin /bin COPY –from=source /lib /lib COPY –from=source /extra . and this container config: { "metadata": { "name": "busybox" }, "image":{ "image": "localhost/test" …
On CRI-O, an arbitrary systemd property can be injected via a Pod annotation: — apiVersion: v1 kind: Pod metadata: name: poc-arbitrary-systemd-property-injection annotations:
A flaw was found in CRI-O that involves an experimental annotation leading to a container being unconfined. This may allow a pod to specify and get any amount of memory/cpu, circumventing the kubernetes scheduler and potentially resulting in a denial of service in the node.
Impact It is possible to craft an environment variable with newlines to add entries to a container's /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry. Note: because the pod author is in control of the container's /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes. Patches 1.26.0 will …
Incorrect handling of the supplementary groups in the CRI-O container engine might lead to sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in github.com/cri-o/cri-o.
A flaw was found in cri-o, where containers were incorrectly started with non-empty default permissions. A vulnerability was found in Moby (Docker Engine) where containers started incorrectly with non-empty inheritable Linux process capabilities. This flaw allows an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs.
Before setting the sysctls for a pod, the pods namespaces must be unshared (created).
A flaw was found in CRI-O in the way it set kernel options for a pod. This issue allows anyone with rights to deploy a pod on a Kubernetes cluster that uses the CRI-O runtime to achieve a container escape and arbitrary code execution as root on the cluster node, where the malicious pod was deployed.
An incorrect sysctls validation vulnerability was found in CRI-O. The sysctls from the list of "safe" sysctls specified for the cluster will be applied to the host if an attacker is able to create a pod with a hostIPC and hostNetwork kernel namespace.