Rmcnamara-Snyk

**Name of the Vulnerable Software and Affected Versions** Incus versions 6.21.0 and below IncusOS (affected versions not specified) **Description** Incus is a system container and virtual machine manager. A flaw exists where a user capable of launching containers with custom images (e.g., a member of the ‘incus’ group) can leverage directory traversal or symbolic links within the templating functionality to achieve arbitrary file read and write access on the host system. This can ultimately lead to arbitrary command execution on the host. Specifically, when an image utilizes a `metadata.yaml` file containing templates, the source and target paths are not adequately validated for symbolic links or directory traversal. This allows an attacker to read arbitrary files from the host filesystem and write files to arbitrary locations, potentially overwriting critical system files. Exploitation on IncusOS requires a minor modification to the stage2 process. The vulnerability allows a user to read arbitrary files from the host filesystem and write files to the host filesystem as root. **Recommendations** For Incus versions 6.21.0 and below, apply a fix as it becomes available. For IncusOS, apply a fix as it becomes available.

**Name of the Vulnerable Software and Affected Versions** Incus versions 6.20.0 and below **Description** Incus is a system container and virtual machine manager. A user with the ability to launch a container with a custom YAML configuration can create an environment variable containing newlines. This can be used to add additional configuration items in the container’s lxc.conf due to newline injection, potentially allowing the addition of arbitrary lifecycle hooks, ultimately resulting in arbitrary command execution on the host. Exploiting this issue on IncusOS requires a slight modification of the payload to change to a different writable directory for the validation step. The `lxc.conf` file is affected. **Recommendations** Versions prior to 6.20.0 are affected. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: OpenPrinting CUPS versions 2.4.8 and earlier Description: The issue is related to the cupsd server, which can be caused to perform an arbitrary chmod of the provided argument when starting with a Listen configuration item pointing to a symbolic link. This can result in world-writable access to the target, allowing the change of permission of any user or system files to be world writable. On Ubuntu systems, this vulnerability is limited to those files modifiable by the cupsd process. It is possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Recommendations: For OpenPrinting CUPS versions 2.4.8 and earlier, apply the patch from commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d to resolve the issue. As a temporary workaround, consider restricting access to the Listen configuration item and the `FoomaticRIPCommandLine` argument to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** snapd (affected versions not specified) **Description** The issue is related to the snapctl component within snapd, which allows a confined snap to interact with the snapd daemon to take certain privileged actions on behalf of the snap. It was found that snapctl did not properly parse command-line arguments, allowing an unprivileged user to trigger an authorized action on behalf of the snap that would normally require administrator privileges to perform. This could possibly allow an unprivileged user to perform a denial of service or similar. The vulnerability may also allow a remote attacker to elevate their privileges. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Buildah versions prior to the fixed version Podman versions prior to the fixed version **Description** A flaw was found in Buildah and Podman, which allows containers to mount arbitrary locations on the host filesystem into build containers. A malicious Containerfile can use a dummy image with a symbolic link to the host filesystem as a mount source and cause the mount operation to mount the host filesystem during a build-time RUN step. The commands inside the RUN step will then have read-write access to the host filesystem, allowing for full container escape at build time. Users running containers with root privileges are impacted, 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. **Recommendations** To resolve the issue, apply the patch to Buildah, which will then be vendored into Podman. Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With "setenforce 0" set, the root file system is open for modification with this exploit. With "setenforce 1" set, files cannot be changed, but the contents of the `/` directory can be displayed. As a temporary workaround, consider disabling the `build` function in Podman and Buildah until a patch is available. Restrict access to the `build` command to minimize the risk of exploitation. Avoid using the `--mount=type=bind` option in the `build` command until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** BuildKit versions prior to 0.12.5 **Description** The issue is related to a race condition that can occur when two malicious build steps run in parallel, sharing the same cache mounts with subpaths. This can lead to files from the host system being accessible to the build container. **Recommendations** For versions prior to 0.12.5, update to version 0.12.5 to resolve the issue. As a temporary workaround, consider avoiding the use of BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.

**Name of the Vulnerable Software and Affected Versions** BuildKit versions prior to 0.12.5 **Description** The issue is related to improper authorization in BuildKit, allowing a remote attacker to run containers with elevated privileges. BuildKit provides APIs for running interactive containers based on built images, and it was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special `security.insecure` entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. **Recommendations** For versions prior to 0.12.5, update to version 0.12.5 or later to fix the issue. As a temporary workaround, consider avoiding the use of BuildKit frontends from untrusted sources. Restrict access to the `security.insecure` entitlement to minimize the risk of exploitation. Avoid using the APIs for running interactive containers based on built images until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** BuildKit versions prior to 0.12.5 **Description** A malicious BuildKit frontend or Dockerfile using `RUN --mount` could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. The issue is related to incorrect restriction of the path name to a directory with limited access, which may allow a remote attacker to delete arbitrary files outside the container. **Recommendations** For versions prior to 0.12.5, update to version 0.12.5 to resolve the issue. As a temporary workaround, consider avoiding the use of BuildKit frontends from an untrusted source or building an untrusted Dockerfile containing the `RUN --mount` feature.

**Name of the Vulnerable Software and Affected Versions** runc versions 1.0.0-rc93 through 1.1.11 containerd versions 1.4.7 through 1.6.27 containerd versions 1.7.0 through 1.7.12 Docker versions 20.10.8 through 24.0.8 Docker versions 24.0.9 through 25.0.2 **Description** An internal file descriptor leak in runc, a CLI tool for spawning and running containers on Linux according to the OCI specification, allows for multiple container breakouts. The issue occurs because a file descriptor remains open during the `setcwd(2)` operation, even when `O CLOEXEC` is used on all descriptors before executing container code. This allows a reference to be maintained within the container by configuring the working directory to a path resolved through that file descriptor. Exploitation can occur in several ways: - A newly-spawned container process via `runc exec` can have a working directory in the host filesystem namespace, granting access to the host filesystem. - A malicious image can use `runc run` to gain access to the host filesystem. - Variants of these methods can be used to overwrite semi-arbitrary host binaries, leading to a complete container escape and arbitrary code execution outside the isolated environment. **Recommendations** Update runc to version 1.1.12. Update containerd to version 1.6.28 or 1.7.13. Update Docker to version 24.0.9 or 25.0.2. As a temporary mitigation, close all unneeded file descriptors to prevent the leak from being exploited.