Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Why spend so much effort on such a relatively useless feature unless there is another reason for it?

Because it's not only Secure Boot really. It's just one part of a larger set of firmware hardening methods called Device Guard (since 2016), which is also a part of Secured Core. (which was mentioned in the article).

> Bootloader attacks are neither common, nor does it seem likely that "secure boot" keeps out a really determined attacker.

Because an increasing amount of PC's have Secure Boot enabled and few attacks really are conducted by a "really determined attacker".



> Because an increasing amount of PC's have Secure Boot enabled and few attacks really are conducted by a "really determined attacker".

But these few attacks are the only ones against which "secure boot" might help, and it probably doesn't. Bootloader attacks were extremely rare to nonexistent even before "secure boot".


> Bootloader attacks were extremely rare to nonexistent even before "secure boot".

Playing devil's advocate: boot sector viruses were common back then. Secure Boot completely avoids both them and their UEFI equivalent, which is probably why we don't see them anymore.


It's not really devil's advocate. It's no longer trivial and is increasingly less so, for random malware that has acquired high privileges to compromise the entire boot sequence.


Boot sector viruses were already hardly common before Secure Boot. Practically since anything that is not MS-DOS-based, it is not that easy to write to the hard disk boot sector from a running operating system, and if you can do so, then it is much easier to write your payload somewhere else in the host OS (with all the OS functionality at your disposal) rather than the boot sector.


> Boot sector viruses were already hardly common before Secure Boot. [...] t is not that easy to write to the hard disk boot sector from a running operating system,

I wonder why... could it be that even then the risk was understood and there were attempts to mitigate? I hope you remember the option in BIOS called "Master Boot Record Protection".

Your "it's uncommon now, so it must not be a problem" argument is tedious at best. Precautions were taken, the worst case has been avoided and that's not an argument supporting not having any precautions.

> then it is much easier to write your payload somewhere else in the host OS (with all the OS functionality at your disposal) rather than the boot sector.

Sure, as long as you can launch before the AV or perpetually keep it at bay without making noise. Getting your malware to run sooner or even as part of the system gives you a very valuable advantage. It's ridiculous to even imply that it wouldn't have become a big problem.


> I hope you remember the option in BIOS called "Master Boot Record Protection".

Well you obviously don't remember it. This option was from the DOS era and would have done absolutely nothing for a protected mode OS like Windows since 9x much less NT.

> Precautions were taken, the worst case has been avoided and that's not an argument supporting not having any precautions.

The main precaution here is that operating systems stopped allowing unprivileged executables from writing to the boot sector. That's what made sector boot viruses disappear. That is my point, and anything else is élucubrations on your part. Sector boot viruses were most definitely not a common thing when SB appeared.

> Sure, as long as you can launch before the AV or perpetually keep it at bay without making noise.

What? Do you think the AV is going to let you write arbitrarily to the hard disk but apparently not do any other destructive/ malware action ? I don't know what type of operating system you are running, but most likely it will prevent writing to the boot sector to all unprivileged processes, AV or not. To overwrite the boot loader you literally would need to beat OS level security AND any potential AV, while for most malware payloads users worry bout you only need to beat the AV since the OS couldn't care less.




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

Search: