Linux

8334 readers

292 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

submitted 2 days ago by cm0002@programming.dev to c/linux@programming.dev

28 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] just_another_person@lemmy.world -2 points 1 day ago (3 children)

How are you going to boot something that's encrypted without input to unlock it?

[–] fmstrat@lemmy.nowsci.com 4 points 1 day ago* (last edited 1 day ago) (2 children)

You always "boot something that is unencrypted." You then "mount" the encrypted volumes and load the OS.

This is how people can put an SSH server (dropbear) in initramfs so they can unlock remotely.

The attack is to initramfs, not the encrypted layer.

The order'ish:

[–] just_another_person@lemmy.world -3 points 1 day ago (1 children)

I'm well aware. You're proving my point at mount.

[–] fmstrat@lemmy.nowsci.com 2 points 1 day ago

But.. your original comment is just.. wrong?

This isn't a critical security flaw unless you have the worst partition scheme on your encrypted volumes imaginable.

The default LUKS partition scheme is vulnerable.

It's not even a process flaw at that point, just "possible".

There is a successful POC, it is a flaw.

you can compromise disks once encrypted because everything is happening in an in-memory boot process.

This is not just in-memory. This is modifying the unencrypted part of initramfs on disk. Powering off the machine does not remove the exploit.