Stéphane Graber

Improper certificate validation in the HTTPS listener allows an unauthenticated remote attacker to impersonate a trusted client and gain full access to the cluster and managed virtual machines. The issue exists because the HTTPS API incorrectly validates every certificate in a supplied chain against the trust store instead of only validating the leaf certificate that proves ownership of the private key. By providing a crafted certificate chain containing a trusted client's public certificate, an attacker can authenticate as that client without possessing the corresponding private key. Depending on the privileges of the impersonated client, this can result in root access to the host machine. In MicroCloud environments, public certificates may be intercepted as a member joins the cluster.

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.

Name of the Vulnerable Software and Affected Versions: Linux kernel versions prior to 6.11.0+ Description: The issue is related to an off-by-one error in the alloc flex gd() function in the ext4 filesystem. This error can cause the flex gd->resize bg to be bigger than flexbg size when adjusting resize bg. The problem can be reproduced with specific settings, such as o group = flexbg size * 2 * n and o size = (o group + 1) * group size. An example of the issue is when n=0 and flexbg size=16. The corresponding reproducer involves creating an ext4 filesystem, mounting it, and then resizing it. The issue was fixed by deleting the problematic plus 1 and adding a WARN ON ONCE() to prevent it from happening again. Recommendations: To resolve the issue, update the Linux kernel to a version later than 6.11.0+. As a temporary workaround, consider avoiding the use of the resize2fs command with specific settings that can trigger the off-by-one error. Restrict access to the vulnerable ext4 filesystem to minimize the risk of exploitation. Avoid using the `resize2fs` command with the `-s` option to resize the filesystem until the issue is resolved.

A memory leak issue has been identified in the Linux kernel's openvswitch module. The problem occurs when parsing user-provided actions, as the module may dynamically allocate memory and store pointers in the internal copy of the actions without properly freeing them. This can lead to significant memory leaks, particularly under conditions with a high rate of flow rotation. The issue is difficult to mitigate due to the user's lack of direct control over the datapath flows generated by OVS.

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.

The issue allows local users to gain privileges via a crafted file in a namespace.

The issue is related to the regeneration of iTALC private keys after installation. Due to incorrect regeneration, each installation has the same fixed key, allowing remote attackers to gain privileges.