Bug#1020713: initramfs-tools: RESUME=auto probably a security hole

[Christoph Anton Mitterer]

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.

[Bastian Blank]

On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
> 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?

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

--
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
stardate 4842.6

[Christoph Anton Mitterer]

Am 25. September 2022 20:13:26 MESZ schrieb Bastian Blank <wa...@debian.org>:
>On Sun, Sep 25, 2022 at 08:05:29PM +0200, Christoph Anton Mitterer wrote:
>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.

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.