Уязвимость инструмента управления контейнерными образами Buildah, существующая из-за неверного ограничения имени пути к каталогу с ограниченным доступом, позволяющая нарушителю пользователю повысить привилегии в системе

Уязвимость программного средства управления и запуска OCI-контейнеров Podman, связанная с неправильным ограничением имени пути к ограниченному каталогу, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость программного средства управления и запуска OCI-контейнеров Podman, связанная с неправильной проверкой входных данных, позволяющая нарушителю получить доступ к конфиденциальной информации

Уязвимость библиотеки containers-common языка программирования Golang, связанная с неправильным разрешением ссылки перед доступом к файлу, позволяющая нарушителю получить доступ к конфиденциальной информации

Уязвимость программного средства управления и запуска OCI-контейнеров Podman, связанная с неконтролируемым расходом ресурсов, позволяющая нарушителю вызвать отказ в обслуживании

A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system.

A flaw was found in Go. When FIPS mode is enabled on a system, container runtimes may incorrectly handle certain file paths due to improper validation in the containers/common Go library. This flaw allows an attacker to exploit symbolic links and trick the system into mounting sensitive host directories inside a container. This issue also allows attackers to access critical host files, bypassing the intended isolation between containers and the host system.

A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files.

A vulnerability was found in Buildah. Cache mounts do not properly validate that user-specified paths for the cache are within our cache directory, allowing a `RUN` instruction in a Container file to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah.

A vulnerability was found in Podman, Buildah, and CRI-O. A symlink traversal vulnerability in the containers/storage library can cause Podman, Buildah, and CRI-O to hang and result in a denial of service via OOM kill when running a malicious image using an automatically assigned user namespace (`--userns=auto` in Podman and Buildah). The containers/storage library will read /etc/passwd inside the container, but does not properly validate if that file is a symlink, which can be used to cause the library to read an arbitrary file on the host.