Unsigned header allows attacker to choose vulnerable AES implementation in untrusted cloud host setting
Hi!
I would like to report a potential security issue with LUKS2.
Issue description
The disk header is only checksummed but not cryptographically signed, so it can be easily modified, allowing key recovery attacks in an untrusted cloud setting via downgrading to an insecure AES implementation.
Short background
An increasingly relevant use case for disk encryption is hosting encrypted VMs in the cloud, where the VM owner does not trust the hypervisor (cloud hoster). Modern AMD EPYC CPUs offer the Secure Encrypted Virtualization (SEV) Feature, which includes hardware-level memory encryption and attestation. Intel's upcoming TDX offers similar functionality.
For both technologies, the VM owner gets proof from the hypervisor that their intended OS or boot loader is running. They then send an encrypted disk image, and provide the corresponding key through a secure channel. The VM finally loads and decrypts the disk.
The difference to "usual" physical attacks on disk encryption is that the attacker (i.e., the untrusted hypervisor) can monitor the decryption through microarchitectural side-channels, e.g., cache attacks. All relevant CPUs have support for AES-NI, i.e., a hardware AES implementation that is resistant to all such attacks, so usually that is unproblematic.
The attack
By patching the value of the encryption
field in the segment information header to capi:xts(ecb(aes-generic))-plain64
, the hypervisor can force the Linux kernel to use a software-level implementation of AES. That implementation uses lookup tables, which are highly vulnerable to cache side-channel attacks, allowing the attacker to recover the volume master keys.
Aside from some slowdown, the user wouldn't notice anything: The data is still encrypted/decrypted correctly.
We are currently finishing a proof-of-concept attack.
Potential mitigations
Remove vulnerable crypto from Linux kernel
The kernel should only have hardened crypto primitives. However, only replacing the vulnerable AES implementation is insufficient, as the kernel also has other vulnerable crypto primitives, which the attacker could use. This would cause the disk decryption to fail, but still may yield enough info such that the attacker can reconstruct the volume master keys.
Verify the integrity of the disk header
At the moment, besides the checksum, there does not seem to be a way to ensure that the disk header has not been modified (please correct me if I missed something). A good solution would be including such a means in the LUKS2 specification.
-- Jan Wichelmann, Luca Wilke, Thomas Eisenbarth
University of Lübeck