|
|
Subscribe / Log in / New account

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 21, 2024 20:58 UTC (Wed) by dskoll (subscriber, #1630)
In reply to: This is only a risk for Linux users that have not patched their boot packages in the last 2 years by mussell
Parent article: "Something has gone seriously wrong," dual-boot systems warn after Microsoft update (Ars Technica)

One scenario that you might worry about is PCs that have physical access by not entirely trustworthy people. Think library catalog workstations or Internet access machines, for example.

This is very difficult to defend against for sure, but secure boot is a part of the defense.


to post comments

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 21, 2024 21:13 UTC (Wed) by yeltsin (guest, #171611) [Link] (5 responses)

What stops you from booting a signed image of any Linux distribution and doing whatever you want to that system? A more effective way would be to set a BIOS password and lock down the boot menu, which does not require "secure" boot, and I'm not sure how it can help here. Or hide USB ports completely, if possible (I've seen systems where they were filled with glue to stop people from bringing in malware on USB sticks).

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 21, 2024 21:16 UTC (Wed) by mb (subscriber, #50428) [Link] (4 responses)

>What stops you from booting a signed image of any Linux distribution

The UEFI boot source settings.

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 21, 2024 21:26 UTC (Wed) by yeltsin (guest, #171611) [Link] (3 responses)

That's what I wrote though.

And "secure" boot helps here… how? Either you allow booting from USB devices (and other sources), and the bad guy can boot into any signed image, even if it's the Windows installer (where you can get a shell and do whatever to the system), or you don't snd secure boot is simply unnecessary.

I'm not claiming the world doesn't need it, but I haven't found a use case for it during the 10 or 12 years it's been around, and remembering how much concern it raised when it was introduced I have a feeling we somehow talked ourselves into believing it's a good thing since it was forced down upon us.

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 21, 2024 21:30 UTC (Wed) by mb (subscriber, #50428) [Link]

>And "secure" boot helps here… how?

It's not supposed to.

BitLocker encryption

Posted Aug 22, 2024 15:32 UTC (Thu) by pflugstad (subscriber, #224) [Link] (1 responses)

On my work laptop, secure boot uses the TPM to do BitLocker encryption of the C: drive.

If I disable secure boot, I no longer have access to the TPM keys, so I cannot access the C: drive.

I'm sure there are holes in this, but I think that's the main reason.

So this makes your basic evil maid attack more difficult.

BitLocker encryption

Posted Aug 23, 2024 21:40 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

It's not just evil maid, it's (nearly) the entire category of attacks that involve physical access to storage media (i.e. almost all of the things that full disk encryption is normally designed to protect against). Your device's TPM ensures that it can only be decrypted when it is booted "properly." The operating system then demands your password before you may log in (and probably implements rate-limiting and other protections).

The upshot is that you only have to type your password once (at login time) instead of twice (once at boot to decrypt, and then once at login), while still getting nearly all of the protection of full disk encryption, plus rate-limiting and some ability to deploy additional countermeasures in software (e.g. you can remotely log all login attempts, remotely wipe lost or stolen devices, etc.). While businesses generally tend to be more interested in those use cases than consumers, end users do benefit from smartphones becoming harder to steal.

The only attack I can think of that fails against traditional full disk encryption but might succeed against TPM-based encryption is a cold boot attack. Apparently at least one group has demonstrated[1] that this is possible. But that paper was presented over 15 years ago,[2] so modern systems might use TPMs differently. On top of that, modern smartphones are accidentally highly tamper evident (because manufacturers value thinness over repairability and use glue instead of more reasonable construction techniques).

[1]: https://www.usenix.org/legacy/event/sec08/tech/full_paper...
[2]: https://www.usenix.org/legacy/events/sec08/sec08_sponsor.pdf

This is only a risk for Linux users that have not patched their boot packages in the last 2 years

Posted Aug 22, 2024 0:53 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I don't think SB is meant to protect against an attacker with physical access, it's a minimal protection from your common malware to prevent it from routinely subverting your firmware and early boot before you can get any kind of anti-malware defense running, relegating that kind of APT to well funded nation states, rather than having every one be persistent and unremovable across wipe and reinstall. It's not intended to make Linux more difficult, just makes boot changes harder to hide


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds