Hacker News new | past | comments | ask | show | jobs | submit login

Is there any actual evidence for this? Why are they any harder to deal with than cleaning existing malware? If anything they're easier to detect (just read the boot sectors on the drive and compare vs. a small list of known bootloaders). "Clean up" just requires installing a new bootloader and rebooting. Obviously the malware could try to take steps (load compromised storage drivers, say) to defeat this, but that's equally an option for traditional malware too (e.g. hack the filesystem to hide itself).

Where's the urgency here? What makes this so important?




Without Secure Boot systems, even with full disk encryption, would be vulnerable to repeated evil maid attacks.

>If anything they're easier to detect (just read the boot sectors on the drive and compare vs. a small list of known bootloaders)

That is what Secure Boot essentially does.

edit: to expand: Boot sector malware is easy to detect from outside the system, but you need actively to be looking for it. How many users regularly check their bootsectors with an external OS?


So your counterexample is that secure boot can protect against hard drive encryption breaks. I guess that's fair. But it's not perfect protection (a compromised kernel will give up the keys too). Honestly, given the frequency with which we see kernel exploits in the wild I'd say it's at best incrementally better protection. It's also a hypothetical: are there active evil maid attacks in the wild?

And, of course, my point was that secure boot comes with very non-trivial costs (to freedom of use, primarily). I don't think it's worth it, and your example hasn't convinced me.

And I don't understand the edit. Of course no one checks their bootsectors, just as no one checks hashes of their system files. There's a whole industry of (vaguely useful) software to do this for them. How does a potential new vector change the concept of AV software?


It's only a hypothetical that secure boot is going to have any impact at all on the freedom to use x86 hardware.


It's also only a hypothetical that implementing an "Internet killswitch" or government-mandated ISP website blocking ("for the children" of course) will impact our freedom.

The idea is that with the infrastructure in place, we're ever closer to being impacted.


Sure. I was riffing on the other poster calling the malware prevented by a secure boot scheme a hypothetical.

It's certainly a hairy issue. The ability to run a verified software stack is a real benefit to users. Central control of that verification is bad for users, but a shadow of that central control is the obvious way to make it easy for users that don't know they should care.


In context, I called it a hypothetical because I'd asked for specific examples of boot-time malware that justify the rush to secure boot. This wasn't one.


My point is that you are anticipating problems with secure boot (there is no evidence that it will worsen the situation on general purpose hardware; there are certainly reasons to believe it might) and then dismissing some of the justification because it merely anticipates an attack.


The problem is rootkits booting even before your OS or antivirus can. That way they can run a hypervisor and boot the OS on it or load a malicious filysystem driver that returns a benign boot sector if it's requested and no application or antivirus running on that OS can even know that it's running on top of malware. Secure boot can stop this from happening.

Why is this so hard for everyone to understand?


Stop. I assure you I understand the issues, your patronization isn't appreciated.

Malware can defeat an installed AV already, it certainly doesn't need a hypervisor to do it. Likewise it can (and just did, c.f. the news last week) install a malicious driver without pre-OS hooks.

These are exploits that exist in valid, already-authenticated and running OS code. Secure boot can do nothing to stop it. So why is that so hard for you to understand?


> But it's not perfect protection (a compromised kernel will give up the keys too). Honestly, given the frequency with which we see kernel exploits in the wild I'd say it's at best incrementally better protection.

There is no such a thing as perfect protection. All security is incrementally better protection.


Which is exactly my point.


No, your point is –in your own words– that, since it’s at best incremental protection, it isn’t worth the non-trivial costs. Which is not a good point because, as I said and you agreed, all security is at best incrementally better protection. If that was really your point, we could as well just drop any protection, since none of it is perfect.

You may say the increment in protection is not enough to justify the costs, but that would be a different story.


You've completely lost me. That last sentence? That's what I meant.

The first bit is either a terrible mistake or a deliberate misreading. For the life of me I can't figure out how you think "it isn’t worth the non-trivial costs" (which, by the way, are not my words) and "not enough to justify the costs" mean different things.


You explained this far better than I could - only dedicated, tech-savvy folks would be able to do this.


I was thinking of malicious code in the BIOS firmware, but I'm sure there are other examples. It's hard for the average user to deal with such things - even the supposedly easy example you gave of comparing a drive's boot sectors to a known list of trusted boot loaders.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: