REDHAT-BUG-2499618: High severity cri-o cri-o vulnerability
A flaw was found in CRI-O. CRI-O persists reserved internal sandbox metadata alongside untrusted pod-supplied annotations without adequate separation, allowing a crafted pod annotation to overwrite that reserved state before it is saved to disk; after a CRI-O restart or node reboot, this poisoned value is reloaded as trusted and used by a later container recreate in the same sandbox, which can result in a host-side runtime-management resource being bind-mounted into the container. A container that gains access to this resource may be able to direct the runtime to act with host privileges, resulting in container escape and full node compromise. This does not require a privileged pod, hostPath, or a custom RuntimeClass, only the ability to create a pod plus a subsequent runtime restart/recreate.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Nodes running CRI-O are exposed if an attacker can create a pod on the node and can cause or wait for a subsequent CRI-O restart, node reboot, or container recreation in the same sandbox. Privileged pods, hostPath volumes, and custom RuntimeClass configuration are not required.
What does an attacker need to do to exploit it?
The attacker needs the ability to supply a crafted pod annotation that overwrites reserved sandbox metadata before it is persisted. The poisoned metadata must then be reloaded after a runtime restart or reboot and used during a later container recreation in that sandbox.
What is the potential impact after successful exploitation?
A later container recreation can receive a bind mount of a host-side runtime-management resource. Access to that resource may allow the container to direct the runtime to act with host privileges, leading to container escape and full node compromise.