An improper validation vulnerability in the instancePostMigration function in lxd/instancepost.go of LXD allows an authenticated attacker with cancreateinstances permissions on a restricted project to bypass project-level security restrictions. When migrating an instance between projects, LXD fails to validate the instance's configuration against the target project's enforced restrictions (such as restricted.containers.lowlevel, restricted.devices., and restricted.networks.access). An attacker can exploit this by creating a disallowed or high-privilege instance in an unrestricted project and subsequently moving it into the restricted project.

A path traversal vulnerability in LXD allows an attacker to achieve arbitrary host file read or unconstrained file creation. When processing image metadata templates, LXD fails to properly sanitize or restrict template file paths from escaping the instance templates directory (specifically affecting virtual machine / QEMU driver execution paths). An attacker can exploit this flaw by providing a crafted image archive with malicious template directives containing path traversal sequences, causing LXD to access or write files outside the intended template directory on the host system.

A privilege escalation vulnerability exists in LXD from 6.0 before 6.9, 5.21.0 before 5.21.5, and 5.0.0 before 5.0.7 regarding the handling of project-restriction policies during snapshot restoration.. An authenticated project operator in a restricted multi-tenant environment can bypass policy restrictions by importing a maliciously crafted instance backup containing restricted configuration keys within a snapshot. When the snapshot is restored, these restricted keys are applied to the live instance without policy validation. Starting the modified instance grants the operator unauthorized host root access.

On Wed, Feb 14, 2024 at 02:40:43PM +0000, Mate Kukri wrote: Hello,

We have identified a vulnerability resulting from an insecure default configuration of OVMF/AAVMF and similar firmware as used in Ubuntu's edk2 package, the firmware used by LXD, and potentially other similar software.

Said EDK2 based firmwares implement UEFI Secure Boot functionality but also contain a copy of the UEFI Shell, this gives an OS resident attacker (without physical access or pseudo-physical access) the ability to execute arbitrary code at system level, and thus the ability bypass UEFI Secure Boot. Hi Mate,

I'm not sure if I understand everything correctly, but if UEFI Secure Boot is enabled, shouldn't the shell.efi binary need to be explicitely signed in order for it to be correctly loaded? It doesnt look like a good idea to sign shell.efi on a production platform, but for test purposes it might be relevant.

Regards, -- Yves-Alexis Perez