|
|
Log in / Subscribe / Register

Bottomley: Owning your Windows 8 UEFI Platform

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 12:42 UTC (Mon) by dsommers (subscriber, #55274)
In reply to: Bottomley: Owning your Windows 8 UEFI Platform by ekj
Parent article: Bottomley: Owning your Windows 8 UEFI Platform

> The things she cares about are trojans sniffing things like banking-
> details and passwords, and perhaps weaknesses in browsers or other
> exposed programs that leads to the PC becoming zombied.

True

> Secure boot makes essentially no difference to any of this. If you've
> got a unpatched IE, or an outdated version of Java, or if you
> double-click everything you get in email, you're precisely as screwed
> with or without secure boot.

True too. But you then ignore that secure boot removes an attack vector. That attack vector has not been used as much as it was during the DOS times, where BIOS vendors after a while added features to block writes to the boot sector. Secure boot ensures that the core OS loaded is unmodified. Which can even be seen as an extension of this old "don't write to boot sector" feature.

Secure boot makes it in fact harder to modify the earliest code loaded on a system. If you get trojans, backdoors, keyloggers, etc loaded at the very earliest boot stages, it is also more likely you can hide that code from the end-user's additional security programs. This is the attack vector secure boot can defend against. And the reason such an attack might be possible, is due to lack of secure boot and not properly updated system with latest updates for OS, third-party software and anti-virus/anti-scam/anti-spam/anti-whatever software. Secure boot is an additional layer of security, not a replacement of anything else.

Sure the boot process might not be the easiest attack vector at all, but the end-user side is getting more and more attention through security products, making the currently used attacks harder. Secure boot is just filling a gap, a gap which is best solved hardware wise. And if nothing is done in this area, this is where more attacks will be diverted in the future. And with "nothing", I also include "disable secure boot".

For the end-user, such security mechanisms needs to stay out of their way. Just like firewalls. And that is the current standard. However, firewalls can be tweaked even better, which is not a task the average end-user might care for at all. But the firewall is there with a usually decent protection. Users interested in a higher security level can tweak this to make it harder.

Secure boot is a similar mechanism. Most users shouldn't ever notice it as, as you say, they won't change the OS. But for those who do change the OS; providing mechanisms to have a secure system, even through the boot sequence, is a good idea.

Remember all the fuzz and noise caused when Microsoft enabled the firewall by default in one of the Windows XP service pack? This discussion about secure boot is an iteration of that. But very few hardly complain about that decision nowadays.

But by all means, there are people who disables firewalls, SELinux, authentication mechanisms, etc, etc - and in the future secure boot ... For such users anything which says "increased security" will always be a hassle, no matter what it is, and it will be disabled. That attitude is a failure by default, IMO.


to post comments

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 19:53 UTC (Mon) by hummassa (guest, #307) [Link] (1 responses)

> True too. But you then ignore that secure boot removes an attack vector.

No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.

> That attack vector has not been used as much as it was during the DOS times,

This has a reason: while it may be practical in an embedded and usually homogeneous environment, in a standard-PC env, the attacker must have code to read every one of the one hundred different filesystems if he wants to compromise the system via boot. IOW, the attacker must be an entire OS.

> where BIOS vendors after a while added features to block writes to the boot sector.

This had not detained nor even slowed down malware at that time (yes, I am that old) and it was considered just a nuisance because it difficulted NECESSARY system updates; you know, to patch vulnerabilities &c... Many, many people turned this off in BIOS. Ah, and once you entered another OS, this was not effective because the other OS bypassed BIOS and talked directly to the hardware. THAT is the reason this is not in effect in today's PCs...

> Secure boot ensures that the core OS loaded is unmodified.

Yes. But from a security standpoint, this would ONLY be a good thing if the core OS loaded was PROVEN secure. If you load a swiss cheese of vulnerabilities, unmodified, this is a BAD thing.

> Which can even be seen as an extension of this old "don't write to boot sector" feature.

Yes. Equally uneffective, equally a nuisance, equally time-consuming for no good reason.

Bottomley: Owning your Windows 8 UEFI Platform

Posted Feb 18, 2013 20:21 UTC (Mon) by raven667 (subscriber, #5198) [Link]

>> True too. But you then ignore that secure boot removes an attack vector.
>No, it doesn't, and the proof for that is Apple's products jailbreaks. One of them used a simple crafted PDF that subverted the "secure boot" infrastructure.

Are you sure? Are you saying that there were jailbreaks that were permanent and that can't be removed or detected and that persist across reboots and upgrades of the OS? Are you sure it was the boot infrastructure that was being bypassed, rather than the OS kernel?

>> Secure boot ensures that the core OS loaded is unmodified.
>Yes. But from a security standpoint, this would ONLY be a good thing if the core OS loaded was PROVEN secure. If you load a swiss cheese of vulnerabilities, unmodified, this is a BAD thing.

That is an absurd position to take because you and I both know that the OS kernel is not and never will be "proven" secure, also this is not a claim which is being made by secure boot proponents or by the spec so to defend against claims which weren't made is the creation of a straw man on your part.

Secure Boot can only help prevent permanent, undetectable modification of the firmware and stage 1 bootloader by those not authorized by the system owner (such as malware), what the OS kernel and later code does with this known good system state is up to the implementor, usually they are going to want to push the known good state as far as they can (until arbitrary code which can be under the control of an attacker is run and re-compromises the system), by doing their own signature checking and whatnot.


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