Windows 8 Secure Boot Feature: Not So Secure?

[mediasorcerer]

Thanx for the post qubit, interesting development.Thats the first thing i thought when i first heard of windows 8 secure boot feature=it will be cracked. haha

 

[Lipton]

I honestly have no idea why UEFIs Secure Boot is being brought up here.

"The researcher claims that the real issue exists in legacy boot procedures, not in the Redmond company's new feature." debunks this whole 'article' and the Softpedia headline is sensational driven by speculation.

 

[Yellow&Nerdy?]

Surprise surprise. Seems like Windows 8 might be another Vista.

 

[Lipton]

Surprise surprise. Seems like Windows 8 might be another Vista.

This exploits the legacy BIOS. Not UEFI and has nothing to do with the Windows 8 support of UEFI Secure Boot.

 

[newtekie1]

I would appreciate your list of other OS's implementing this feature. Thanks.

• Linux
• Linux
• Linux
• Linux
• Oh and OSX

Here is a statement from a Kernal Developer at Red Hat:

We don't really support secure boot right now, but that's ok because you can't buy any hardware that supports it yet. Adding support is probably about a week's worth of effort at most.

This exploits the legacy BIOS. Not UEFI and has nothing to do with the Windows 8 support of UEFI Secure Boot.

I'm not sure this exploits the legacy BIOS but rather it exploits the legacy boot method on MBR drives, injecting a signed key before the OS boots, which you are correct in that it has nothing to do with Windows 8. And the simplest fix would just be to require boot drives use GPT when Secure Boot is enabled in UEFI.

 

[Damn_Smooth]

• Linux
• Linux
• Linux
• Linux
• Oh and OSX

Here is a statement from a Kernal Developer at Red Hat:





I'm not sure this exploits the legacy BIOS but rather it exploits the legacy boot method on MBR drives, injecting a signed key before the OS boots, which you are correct in that it has nothing to do with Windows 8. And the simplest fix would just be to require boot drives use GPT when Secure Boot is enabled in UEFI.

So Linux is switching to secure boot also? Or they have to because of UEFI?

 

[newtekie1]

So Linux is switching to secure boot also? Or they have to because of UEFI?

They don't have to, as Secure Boot is supposed to have the option to be disabled in the UEFI interface. Most of the free distros probably won't see Secure Boot support. However, enterprise supported version of linux, such as Red Hat and the others that see heavy use in the enterprise world, will be using Secure Boot for sure.

 

[scaminatrix]

I must give him the benefit of the doubt since he seems to be hating on the entire IT industry, not just the two or three companies.

well, at least you can't say he's biased!

 

[qubit]

Calm down people, everyone is wrong, especially me.

While qubit might be bringing a Charlie Demerjian vibe to TPU, I must give him the benefit of the doubt since he seems to be hating on the entire IT industry, not just the two or three companies. The "Secure Boot" feature seems to be misunderstood as we don't all know exactly what it is.

We browsed the "reports" (not just the TPU versions) and since all of them are heavily biased they try to make Windows 8 (and Microsoft) the bad guy here. It wouldn't be news if it wasn't about a new, shiny (unreleased) product.

The attack described in this article seems to not be geared towards Windows 8 to be fair. Since the attack patches the MBR and then uses an inherent OS problem to obtain elevated rights it looks like Vista, Windows 7, Windows Server 2008 (R1/R2) and possibly others that support UEFI (or any hybrid UEFI version) can be attacked in the exact same way, and I don't see it now how it is related to UEFI or the secure boot feature.

To this looks to be nothing more then a puny OS vulnerability (like hundreds before it and hundreds after it) made to look like UEFI/Microsoft are the bad guys here. It will get patched, before or after the OS ships. Even more it is a vulnerability that first attacks the legacy part of the OS, and I thought that UEFI is the step away from legacy.

So it looks to me like UEFI and Microsoft should make the secure boot feature even more closed and draconic in nature in order to protect their customers. And in this way the reports are contradicting in nature, since half of them complain about the feature locking out Linux and other fluffy things like that while the other half complain about it letting in governments and other not-so-fluffy things.

I remember the same reaction when Microsoft introduced the driver signature enforcement in Vista, everyone automatically switched to panic mode, but in the end all was good.

Like then, everyone is now overreacting, trying desperately for their 15 minutes in the spotlight, and in a way, "Windoze 8 is the D3vil" articles will bring in many visitors to any site, visitors that will translate into add revenue.

Great post.

But sheesh, I didn't think I hated the whole IT industry?

The vulnerability isn't in the OS itself. From the looks of it, the UEFI still contains legacy BIOS code that's causing the problem, as the MBR isn't checked. Once that code is updated, this vulnerability will be fixed. Therefore, it's fair to say that any OS, Linux etc at this point would be vulnerable to Stoned Lite.

Hopefully you're right about all this being an overreaction. Only time will tell for sure, but in the meantime, the previous stories I linked to explain why it's a potential problem and people shouldn't be complacent about it.

Secure boot also sounds like it will make security software redundant, doesn't it? I suspect that it won't in practice, though.

 

[[H]@RD5TUFF]

I really hope this is true, as I don't want to have to give up linux.

 

[newtekie1]

I really hope this is true, as I don't want to have to give up linux.

You won't have to anyway, secure boot can be disabled by the user in UEFI. That is in the spec for Secure Boot. However, the option isn't required, so we will probably see some OEM machines that have that option missing from UEFI. So just build your own machines and you won't have that problem.