Oops - Microsoft opens Secure Boot by mistake, showing everyone why master keys are a bad idea.

[Michael McAllister]

So does this vulnerability apply to the motherboard itself?  According to my System Information page, I do not have Secure Boot enabled in the OS, but I do have a UEFI BIOS.

[GoodBytes]

53 minutes ago, Dan Castellaneta said:

Probably should've clarified.

Windows 7 does not enforce it by default.

No, it doesn't support it.

[PlayStation 2]

7 minutes ago, GoodBytes said:

No, it doesn't support it.

Fuck, never mind, I'm thinking of UEFI support.

[FPS-Russia]

I don't have a UEFI capable bios and i have Win 10. Does this affect me?

[GoodBytes]

1 minute ago, FPS-Russia said:

I don't have a UEFI capable bios and i have Win 10. Does this affect me?

No. Because you don't have the protection. So, it is like Secure Boot is disabled on your system.

[FPS-Russia]

Just now, GoodBytes said:

No. Because you don't have the protection. So, it is like Secure Boot is disabled on your system.

Thank you.

[Michael McAllister]

10 minutes ago, GoodBytes said:

No, it doesn't support it.

Went into the UEFI and changed the Secure Boot option to 'Other OS' but it still says that it's enabled.  Don't see an option in the UEFI other than 'Other OS' or 'UEFI Windows'.  Am I missing something?

[TetraSky]

Never used secure boot, it was enabled by default on my tablet, disabled it when I saw it prevented me from booting off a usb drive to install Windows 10.

[Michael McAllister]

5 minutes ago, GoodBytes said:

No. Because you don't have the protection. So, it is like Secure Boot is disabled on your system.

Kind of ironic that having the protection is more dangerous than not having it.

[AlexGoesHigh]

8 minutes ago, Michael McAllister said:

Kind of ironic that having the protection is more dangerous than not having it.

Is more like they are the same, is just a barrier that now has a easy to hit sweet post so it can be demolished, with it off is like there's no wall at all.

[SeriousDad69]

On 8/10/2016 at 4:05 PM, KrumpetPirate said:

@SSL with heartbleed icon, @AlexTheRose with an arch icon in a thread about M$ screwing up? lol

 

I agree with Alex on this one, this was an anti-consumer move from the outset. It sucks that there is a vulnerability now where none should have existed.

That's the Arch Linux icon? I thought it was a fat guy standing in front of a giant cool ranch dorito lol

[iamdarkyoshi]

Anything I could do on my dell venue 8 pro tablet with this? I don't see the point, its already running windows 10 desktop...

[LucidMew]

Aw man, give credit to the original source https://rol.im/securegoldenkeyboot/ with some awesome keygen chiptunes to go along with it!

[TheReal1980]

This is why I run my business on other OS, I never trust Windows for anything.

[deviant88]

its good to see microsoft's bollocks breaks down, next the UWP and Store please

[LAwLz]

For anyone reading this, "master key" is a bit misleading, too nice sounding for my taste.

What actually happened is that Microsoft had built a backdoor in their secure boot, and that backdoor has now been exposed (what a surprise that a Microsoft product has backdoors in it, right?).

 

 

The "gibberish" the author of the register seems to have mistaken for the private key is in fact a hash, not a key.

The big clock of random letters and numbers is not the key used to "encrypt" something, it is the result of the "encryption", and it is not a two way street.

 

 

On 8/10/2016 at 10:16 PM, GoodBytes said:

Its downside is that it prevents open source boot loaders and therefore: Linux distros (as they use an open source boot loaders) to take advantage of this security feature. Why? because it needs a key which can't be shared, but being open sources, it needs to be shareable to others else people can't do much with the source code, beside removing the code for it, and not support Secure Boot. If the key is public, it breaks the point of secure boot, as rootkit makers, can just use one of the many keys that anyone has access from an open source boot loader, and voila, their rootkit is not "validated", and it will install just fine, making the whole thing useless. So because these open source boot loader has no support for it, it needs to ask the user to turn it off. Ubuntu is one of the few non-Windows OS that support Secure Boot, where that part of its boot loader isn't open source.

This is not true, at all.

I can barely even explain how it is wrong because it would require explaining the basics of asymmetrical encryption and hashing. So for now, the explanation "the private key does not need to be included in the source code" will have to be enough. In fact, the first-stage boot loader Shim (in Ubuntu and Fedora) has been signed (with permission from Microsoft) using Microsoft's key for several years now, and it is open source (but the key is not publicly known).

 

 

The problem with Secure Boot is not "it doesn't work with Open Source stuff". The problem is that it is up to the motherboard manufacturers to give full control to users, or not.

• On Windows RT (as well as Windows Phone, HoloLens and some other devices) Microsoft has said that the system manufacturer are not allowed to give users any control over Secure Boot. It should be on and it should not be possible to turn it off or alter it.
• On x86 the motherboard manufacturers can expose as much or little control to users as they want, as long as Secure Boot is turned on by default.

 

The thing is, all these trusted certificates has to be loaded into the UEFI out of the factory (if the motherboard doesn't allow users to change the trusted/untrusted certs, or if you want convenience). Motherboard manufacturers will obviously add Microsoft's cert because they expect users to run Windows, but for everyone else developing an OS (or any software that is part of the boot chain really) they would have to go to each and every motherboard manufacturer, prove to them that their certificate is safe and protected (because if the key is leaked then there will be headlines like "Asus motherboards are at risk!"), and then beg for the manufacturer to include their public key in the list of trusted certs.

 

Each OS maker would have to go to something like 30 different motherboard manufacturers and try and convenience them to include their key in the Secure Boot white list. And even if that were to happen, you'd still have to look up "does this motherboard support my particular distro" because your motherboard might have been made before the cert for a particular distro was included. It becomes a nightmare. And if one cert gets leaked, all systems with that cert becomes vulnerable.

 

 

Microsoft could actually have made Secure Boot harmless by mandating that users should have full control over Secure Boot (like how they were mandating that Windows RT users should have 0 control over it). But instead they went the anarchy route because at least they would not be harmed.

 

On 8/10/2016 at 10:16 PM, GoodBytes said:

So, lesson in life: Master Keys are dangerous. They might be convenient, but dangerous. This applies to everything (unless you just don't care).

I got a feeling that some people (maybe even you) is misunderstanding this exploit and assumes it has to do with the keys used for things like signing the components in the boot chain. So this part is written under the assumption that you're talking about those kinds of keys, and not backdoors (which is what this exploit is about).

 

 

1) You make it sound like a master key is something you choose to use, but in reality it is something that is necessary. How do you think a site like LinusTechTips prevents a MITM attack when HTTPS is used? By having a private key which only this particular site knows about. My computer knows that if a packet is signed with this key, it can only be LinusTechTips.Com that sent the packet.

They are not used for convenience, they are used because it is just how this type of encryption and signing works.

 

2) They are not dangerous. Hell, not even in this case the private key was actually leaked (the headline is wrong). The keys need to be guarded and failure to do so will have consequences, but the same can be said for any encryption.