Package: initramfs-tools Version: 0.142 Severity: important Tags: security
Hey. According to initramfs.conf(5): > RESUME > Specifies the device used for suspend-to-disk (hibernation), > which the initramfs code should attempt to resume from. If this > is not defined or is set to auto, mkinitramfs will automatically > select the largest available swap partition. Set it to none to > disable resume from disk. AFAIAU, this means that Debians initramfs would, per default, take the biggest swap found when booting and use that for un-hibernation. Isn't that a rather simple security hole for an attacker with local access to the system to easily defeat full disk encryption with dm-crypt (in combination with booting from a safe USB) and to a certain extent secure boot? All an attacker would need to do, is silently attack a USB stick with some big enough swap partition to the system and wait for the rightful owner to boot with the safe boot-USB stick (which e.g. contains the key to unlock the encrypted system. The initramfs on that safe boot-USB would then automatically pick up the swap from the attacker's USB,... and then game over. Even outside the FDE scope, I can think of scenarios where this allows attacking a system that would otherwise be secure. That's a bit constructed, but just in order to get the idea: Take an ATM, which for an attacker is physically not fully available, though some USB port is. The machine is considered secure, as regularly it wouldn't execute anything from USB unless the client (e.g. a debug console) authenticates. But if the initramfs would un-hibernate from it, that woud likely circumvent such protections. All the attacker would need to do is gain access to the servinging USB port and then trigger a reboot (e.g. via power outage). I think the simplest solution for this would be to just not automatically resume AND to warn people in the manpage, that when in e.g. FDE scenarios they'd need to specify a "safe" device as resume device, i.e. not /dev/disk/by-label/foo but /dev/mapper/myCryptSwap. I further think that even though this whole issue may sound quite simple and not like a super complex attack like some remote code execution, Spectre or rowhammer... it still seems to be a pretty easy way to completely defeat e.g. full-disk-encryption in a way people may not expect. Cheers, Chris.
