Akihirosuda

**Nome do software vulnerável e versões afetadas** Versões do CRI-O Container Engine anteriores à versão corrigida **Descrição** Foi encontrada uma falha no CRI-O, na qual uma propriedade arbitrária do systemd pode ser injetada por meio de uma anotação de Pod. Qualquer usuário capaz de criar um Pod com uma anotação arbitrária pode realizar uma ação arbitrária no sistema host. Isso pode ser feito adicionando anotações como `org.systemd.property.SuccessAction` a um Pod, permitindo a execução de comandos arbitrários no sistema host. **Recomendações** Para versões do CRI-O Container Engine anteriores à versão corrigida, considere implementar um webhook de mutação externo para proibir anotações com o prefixo “org.systemd.property.” a fim de impedir a exploração. Infelizmente, não há informações sobre uma versão mais recente que contenha uma correção para essa vulnerabilidade.

**Name of the Vulnerable Software and Affected Versions** Lima versions prior to 0.16.0 **Description** A virtual machine instance with a malicious disk image could read a single file on the host filesystem, even when no filesystem is mounted from the host. The attacker has to embed the target file path in a malicious disk image, as the qcow2 (or vmdk) backing file path string. Lima refuses to run as the root, making it practically impossible for the attacker to read the entire host disk via `/dev/rdiskN`. The attacker also cannot read at least the first 512 bytes (MBR) of the target file. **Recommendations** For versions prior to 0.16.0, update to version 0.16.0 or later, which prohibits using a backing file path in the VM base image. As a temporary workaround, do not use an untrusted disk image.

**Name of the Vulnerable Software and Affected Versions** runc versions prior to 1.1.5 **Description** The issue is related to rootless runc making `/sys/fs/cgroup` writable under certain conditions, specifically when runc is executed inside the user namespace and the `config.json` does not specify the cgroup namespace to be unshared, or when runc is executed outside the user namespace and `/sys` is mounted with `rbind, ro`. This allows a container to gain write access to the user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host. Other users' cgroup hierarchies are not affected. **Recommendations** To resolve the issue, upgrade to version 1.1.5. For versions prior to 1.1.5, unshare the cgroup namespace by running `(docker|podman|nerdctl) run --cgroupns=private`. Alternatively, add `/sys/fs/cgroup` to `maskedPaths`.