Bug#1020713: initramfs-tools: RESUME=auto probably a security hole
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.
Reply to: