Hacker News new | ask | show | jobs
by kogir 59 days ago
With secure boot, full disk encryption, and robust backups, this risk should be largely mitigated, right?

That’s what I’m personally banking on. I think anyone with the resources to bypass these would first just use a rubber hose.
2 comments
dasyatidprime 59 days ago
Normal/classical FDE doesn't truly protect integrity, only confidentiality. Supposedly LUKS2 allows you to run with --integrity, but it's an extra layer of I/O amplification, and if you're willing to take that hit then there's less incentive not to just use an external drive. https://security.stackexchange.com/questions/87367/does-luks...

As for Secure Boot, maybe? I haven't thought through how that would help in this context, but my instinct is to ask how you'd do the binding between “I intend to boot Y instead of X” and “only accept the boot signature for Y instead of X”, so that malware can't try to unexpectedly substitute X. It feels like there's probably places for attackers to mess around here unless you're very careful.

link
d3Xt3r 59 days ago
Not really. Regular exploits that allow attackers to gain SYSTEM level access frequently crop up in Windows (like the recent regpwn exploit). Someone who games on PC is likely into modding as well, and this is a frequent attack vector - so an innocent-looking mod executable could gain admin rights and make use of secure boot exploits like CVE-2023-24932 (assuming the system is using an unpatched BIOS). Even if the BIOS is patched, there's no guarantee that a similar exploit won't crop up in the future. You could update your system regularly to stay on top of things, but zero days exploits are also a thing - like, do you install updates the minute they come out? Probably not. And even if you do, it takes time to download and apply those updates, a window which could be used to execute zero days, by a hidden RAT.

You don't need any major resources to exploit systems these days in this manner, especially with AI in the mix.

link
snvzz 59 days ago
Many of these attacks target the bios.

BIOS is usually a SPI chip. It'd make sense to perhaps tie the write enable line so that it cannot be written to, unless jumpered.

It used to be a thing motherboards did. A BIOS flash enable jumper.

They kept the CMOS reset one, but for some reason got rid of the flash write enable.

link