An improper neutralization of special elements vulnerability in LXD's NVIDIA instance configuration handling allows an authenticated attacker to inject arbitrary configuration directives. By supplying newline characters within the 'nvidia.driver.capabilities' or 'nvidia.require.' configuration values, an attacker can manipulate the generated lxc.conf file. This flaw enables the attacker to execute arbitrary code on the host system with the privileges of the LXD daemon.

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

LXD before 2.0.2 does not properly set permissions when switching an unprivileged container into privileged mode, which allows local users to access arbitrary world readable paths in the container directory via unspecified vectors.

LXD before 2.0.2 uses world-readable permissions for /var/lib/lxd/zfs.img when setting up a loop based ZFS pool, which allows local users to copy and read data from arbitrary containers via unspecified vectors.