Rmcnamara-Snyk

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.

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.

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.

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.

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.

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.

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.

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.

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. An attacker can maintain a reference to the host filesystem by configuring the working directory to a path resolved through this leaked descriptor. This can be exploited via `runc exec` to set a working directory in the host filesystem namespace or via a malicious image using `runc run` to gain host filesystem access. Furthermore, these methods can be used to overwrite semi-arbitrary host binaries, leading to a complete container escape and arbitrary code execution on the host.