Hey.

According to initramfs.conf(5):

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.

But an attacker can already modify the kernel command line.  Secure boot
up until recently was completely incompatible with hibernation, so
nothing here applies anyway.

Bastian

Am 25. September 2022 20:13:26 MESZ schrieb Bastian Blank <waldi@debian.org>:

As I've explained, not e.g. in a FDE scenario, where one boots from a secure USB stick (which is anyway the only sensible way to do it.

Neither in a scenario as that with the ATM where an attacker could *only* access sind service USB port, but not e.g. a keyboard or anything else.

Cheers,
Chris.