Stgraber

An arbitrary file write issue exists where malicious migration sources can write files to the host system by planting symlinks within transferred volumes. Attackers can craft rsync or btrfs receive streams containing a symlink, such as `rootfs`, that points to the host root directory, enabling them to write files as root and achieve full host compromise.

An arbitrary file write issue exists in the `sftpRecursivePullFile()` function. A malicious incus-agent can escape the target directory during an `incus file pull -r` operation. An attacker with root privileges in a virtual machine can manipulate the process by returning duplicate entries, reporting them first as symlinks and subsequently as files or directories. This allows the attacker to write controlled files, such as `/etc/shadow`, directly onto the operator's host system.

A restriction bypass allows restricted project users to utilize pull mode migration through clustered refresh requests. An attacker with instance creation rights can send a refresh migration request for an existing instance, forcing the server to open outbound TLS websocket connections to probe reachable services.

An improper authorization issue allows restricted TLS clients to read storage bucket keys within the default project. By querying the bucket keys endpoints, attackers can obtain S3 access and secret keys, enabling them to read, modify, or delete objects stored in those buckets.

A project restriction bypass exists that allows restricted project users to set `block.create options` during volume update, copy, and move operations. An attacker can apply this option to a custom volume and initiate a copy or move to a formatting pool, enabling the injection of arguments into the `mkfs` function executed with root privileges.

An authorization flaw exists in the 'GET /1.0/operations/{uuid}' endpoint. This allows clients restricted to a specific project to access operation details from other projects. An attacker with a restricted certificate and a known `uuid` can retrieve sensitive information, including command lines, environment secrets, websocket secrets, and trust enrolment tokens.

A signature verification flaw exists in the built-in S3 server. This issue allows holders of presigned URLs to inject unsigned `x-amz-*` headers. Specifically, an attacker can add an unsigned `X-Amz-Copy-Source` header to a presigned upload URL to copy other bucket objects onto the granted key, which leads to the disclosure of their contents and ETags (Entity Tags, which are unique identifiers for a specific version of a resource).

A path traversal issue exists where clients with permissions to create instances can write files to the host system. This occurs due to unvalidated dependent custom volume names within the instance backup `index.yaml` files. An attacker can import a specially crafted instance backup containing `../` sequences in the dependent volume names to create root-owned directories with controlled content, which can lead to full host compromise.

An authorization bypass allows project-restricted clients to copy volumes by omitting the `source.type` variable. Attackers can send crafted POST requests to the custom volumes endpoint using a specific `source.project` to copy and read volumes, snapshots, and configuration from other projects.

The default configuration of systemd-cryptenroll, as used by IncusOS through mkosi, allows an attacker with physical access to the machine to access encrypted data without requiring interaction from the system owner or tampering with Secure Boot or the kernel image. This is due to the LUKS key being available from the TPM if the PCR7 value is expected and the PCR11 policy matches, allowing the key to be released to the booted system. An attacker can substitute the original encrypted root partition with one they control, prompting for a recovery key which they have defined. A systemd unit within the attacker's root partition can then retrieve the encryption key of the real root disk, enabling data theft or alteration before returning the system to its original state. The attack is possible even with Secure Boot enabled, as the initrd selects the root disk based on GPT partition identifiers. The issue impacts all IncusOS users, particularly those in unsecured physical environments. The attack involves altering the GPT partition table, creating a new LUKS encrypted partition, and using a systemd unit to extract the key.

An issue in AppArmor allows an attacker to possibly have increased attack surfaces of processes that were intended to be confined by AppArmor. This is due to incorrect handling of unknown AppArmor profiles in AppArmor init scripts, upstart jobs, and/or systemd unit files. The common logic to handle 'restart' operations removes AppArmor profiles that aren't found in the typical filesystem locations, such as /etc/apparmor.d/. Userspace projects that manage their own AppArmor profiles in atypical directories are affected by this flaw.

The issue is related to insufficient access control to files in the Ubuntu operating system, specifically in the lxd package. It allows a local attacker to gain privileges through unspecified vectors due to world-readable permissions for /var/lib/lxd/unix.socket.