Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 5.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? Users running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed. Patches From @nalind . This is a patch for Buildah (https://github.com/containers/buildah). Once fixed there, Buildah will be vendored into Podman. Reproducer Prior to testing, as root, add a memorable username to /etc/passwd via adduser or your favorite editor. Also create a memorably named file in /. Suggest: touch /SHOULDNTSEETHIS.txt and adduser SHOULDNTSEETHIS. After testing, remember to remove both the file and the user from your system. Use the following Containerfile To Test Testing with an older version of Podman with the issue As part of the printout from the build, you should be able to see the contents of the /' and /etc directories, including the /SHOULDNOTSEETHIS.txt file that you created, and the contents of the…
Recommended action: Upgrade to 4.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Time-of-check Time-of-use (TOCTOU) flaw was found in podman. This issue may allow a malicious user to replace a normal file in a volume with a symlink while exporting the volume, allowing for access to arbitrary files on the host file system.
Recommended action: Upgrade to 4.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in buildah. Incorrect following of symlinks while reading .containerignore and .dockerignore results in information disclosure.
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An incorrect handling of the supplementary groups in the Podman container engine might lead to the 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.
Recommended action: Upgrade to 4.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Podman in libpod before 1.6.0. It resolves a symlink in the host context during a copy operation from the container to the host, because an undesired glob operation occurs. An attacker could create a container image containing particular symlinks that, when copied by a victim user to the host filesystem, may overwrite existing files with others from the host.
Recommended action: Upgrade to 1.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug was found in Podman where containers were created with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.
Recommended action: Upgrade to 4.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.