Yeah, no duh. This isn't a critical security flaw unless you have the worst partition scheme on your encrypted volumes imaginable. It's not even a process flaw at that point, just "possible".

This is essentially what the Israeli government did to Android a decade ago with Pegasus: if you can get in front of the bootloader, you can compromise disks once encrypted because everything is happening in an in-memory boot process.

Same way you can hotwire cars. It's not new.

[–] BlameTheAntifa@lemmy.world 9 points 1 day ago (1 children)

What’s the expression? If someone has physical access to your machine it’s no longer your machine.

[–] caseyweederman@lemmy.ca 2 points 1 day ago

XKCD about hacking in reality, a $5 monkey wrench, some rope, and kneecaps

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

I'm confused.

Initramfs is unencrypted in /boot when using LUKS with RAID. It has to be, right?

The attacker uses a debug shell to modify the unencrypted boot, so the next time you boot and type your LUKS password, they can gain access.

This doesn't line up with your comment?

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

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

[–] fmstrat@lemmy.nowsci.com 4 points 2 days ago* (last edited 2 days ago) (1 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:

Boot
Initramfs loads, gives you the LUKS prompt
Initramfs decrypts/mounts OS
OS loads

[–] 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.

[–] unexposedhazard@discuss.tchncs.de -1 points 2 days ago (1 children)

Physical access = electronic waste

Thats how it has always been and always will be. If a threat actor had free access to your device for even just a couple seconds, its compromised rare earth trash.

[–] just_another_person@lemmy.world 5 points 2 days ago (2 children)

Nope

[–] ulterno@programming.dev 5 points 2 days ago

Nope

Exactly.
Silicon is not a rare earth element.
Neither is Aluminium nor plastic nor Lithium (it's getting rarer alright, but doesn't fall into the category).

The amount of rare earth elements is really small in these devices.

[–] unexposedhazard@discuss.tchncs.de 2 points 2 days ago (3 children)

Explain. The way i understand it, if somebody flashes malware into your firmware or bootloader then that device cant really be guaranteed to ever be safe again.

[–] 9tr6gyp3@lemmy.world 4 points 2 days ago

Secure boot helps protect against evil maid attacks by checking hardware and OS signatures. If the boot process has been tampered with, the user can be alerted that the secure boot process can no longer properly verify signatures.

While its probably true that you can no longer guarantee that system can be used safely ever again, at least you will be aware that it was tampered with and you can go ahead and send that system to e-waste and get you a new system.

[–] amino@lemmy.blahaj.zone 2 points 1 day ago* (last edited 1 day ago)

i know this is not for PCs but GrapheneOS uses the Google Titan chip and this app to solve that problem.

might be a long time before we get similar hardware for PCs. the only thing that's remotely similar is the Apple T2 for MacBooks but there's no Linux distro with comparable security to GrapheneOS yet.

[–] Jumuta@sh.itjust.works 1 points 2 days ago (1 children)

a raspi, soic8 clip and coreboot

[–] amino@lemmy.blahaj.zone 1 points 1 day ago (1 children)

isn't coreboot strictly for x86?

[–] Jumuta@sh.itjust.works 2 points 1 day ago* (last edited 1 day ago)

you use a soic8 clip and the raspi to connect directly to the SPI ROM on some other computer so you can flash coreboot on it without any obstructions

[–] Infernal_pizza@lemmy.dbzer0.com 20 points 2 days ago (1 children)

If someone has physical access then surely they can change the initramfs without having to use the debug shell?

[–] 9tr6gyp3@lemmy.world 6 points 2 days ago* (last edited 2 days ago) (2 children)

It seems the issue here is that initramfs is not signed, which makes this attack possible.

If it is signed and an evil maid modifies the initramfs itself, it will break the secure boot process and the user will be notified that their system has been tampered with. This should indicate that the secure boot protection is working.

If initramfs is not signed and it drops to the debug shell, then the attacker can make any changes to your system without it affecting secure boot, since it has already passed the protection. At least that's my understanding when I read this.

[–] Laser@feddit.org 10 points 2 days ago (1 children)

This is true, unfortunately some Linux users have been conditioned to "just turn off Secure Boot" without understanding what this actually means and entails.

[–] ulterno@programming.dev 3 points 2 days ago (1 children)

I am guilty of this too.

Despite considering that I need to setup secure boot for my laptop, I have kept it on hold for a bit too long.
But then again, considering the area I am in, I can hardly expect someone to try and steal my data or try to put a ransomware or similar thing, if it means having to get physical access for it. Much higher chance for someone to just steal and sell the thing as is.

[–] Laser@feddit.org 6 points 2 days ago (1 children)

There are probably cases where turning off Secure Boot is fine. If you make that decision for yourself and are aware of the implications, go ahead. My remark wasn't against users turning it off, but rather against the advice of "just turn it off lol"

[–] ulterno@programming.dev 1 points 2 days ago

“just turn it off lol”

Yeah, that's probably just people who read the initial comments from back when secure boot keys were not user configurable (and support wasn't available in Linux) and kept on echoing it all the way to the present.

Kinda similar to the "Linux is just secure" echoers, who might have started from some proper argument explaining what kinds of security problems don't exist in systems developed using Linux and why they don't require installing a 24/7 antivirus background process. Because people tend to make catchphrases. I too sometimes, forget the implications and tend to make them.

[–] Infernal_pizza@lemmy.dbzer0.com 1 points 2 days ago (1 children)

That makes sense. Would a signed initramfs be possible though? Since it's usually rebuilt after most system updates?

[–] 9tr6gyp3@lemmy.world 2 points 2 days ago

Depends on the OS, but you can generally have mkinitcpio handle generating new UKIs after updates and also have it trigger something like sbctl to re-sign images.

[–] Laser@feddit.org 9 points 2 days ago

This is an issue with these half-baked security solutions.

Don't get me wrong: the setup protects against some very common threats (i.e. device gets stolen). But they're unsuited for evil maid attacks.

Secure Boot isn't flawless, but it can improve system security if used correctly; unfortunately, most distributions don't go all the way as demonstrated here. I guess this can be solved via UKIs, but anything built on the users machine like an initramfs can't be signed properly if no user TPM keys are enrolled and available during generation.

The issue I have with all this is that these distributions don't really tell you that the security they provide is ultimately limited. Personally, I have custom TPM keys, the initramfs is signed, I unlock via TPM PIN and the emergency mode is disabled. Also UEFI needs to be password protected so that an attached can't modify your booting parameters, though this couldn't be done undetected because it'd break TPM supported boot.

[–] bitwolf@sh.itjust.works 6 points 1 day ago (1 children)

On the bright side, hopefully this accelerates the UKI initiatives on the different distros.

That would get us a pathway to a fully working secure boot and hibernation on encrypted volumes.

[–] possiblylinux127@lemmy.zip 1 points 1 day ago

Last time I checked the windows implementation was also flawed