9 ms·
From the mailing list: "We believe that the intention of secure boot is to protect against malicious use or modification of pre-boot code, before the ExitBootS
by pieter 14y ago
From the mailing list:
"We believe that the intention of secure boot is to protect against
malicious use or modification of pre-boot code, before the
ExitBootServices UEFI service is invoked. Currently, this call is
performed by the boot loader, before the kernel is executed.
Therefore, we will only be requiring authentication of boot loader
binaries. Ubuntu will not require signed kernel images or kernel
modules."
That's completely different from what Fedora is doing (signing all kernels and modules). I hope for them Microsoft agrees with their interpretation and won't revoke their signed binaries. I'm not sure what advantage they would get from a signed boot loader, if you can run any arbitrary kernel from within the loader.
- ajross 14y agoI was wondering about this too. From the user's perspective, this is great, as it basically means that everything downstream from the custom UEFI bootloader can be unsigned, user-defined code. But at the same time, it pretty clearly defeats the purpose of the UEFI signature chain. A plausible malware vector would thus be to install the ubuntu loader, which then loads your malware payload and chains to windows, compromising the "secure" boot. Basically, it undoes secure boot entirely. Which is a good thing. I hope Microsoft is willing to look the other way on this, but I fear that they are not.
- wissler 14y agoAKA boiling frog.
- gcb 14y agoAny and every malware will be signed with windows (version of the year) private key. They will have way less difficulty to run than oss
- gtsc 14y agoUh, how exactly? The whole point of the private key is that it's only known to MS...
- gcb 14y agoYou seem to be new to all this "centralized control" thing... Here's your complimentary link http://arstechnica.com/security/2012/06/flame-malware-was-signed-by-rogue-microsoft-certificate/ http://arstechnica.com/security/2012/06/flame-malware-was-si... Then you can proceed searching for ssl cert fiasco...
- jerf 14y agoIt is a fallacy to assume that because private keys have been leaked in the past, private keys will necessarily be leaked in the future. Remember, the DRM-can-never-work argument doesn't apply here. DRM-can-never-work is that the user must be supplied the decryption key with the encrypted content. That does not apply to signing; you must be supplied the public key, but the private can be held private.
- jaybill 14y agoHow is that a fallacy? I think the fact that private keys have been leaked in the past demonstrates that they will be leaked in the future.
- cooldeal 14y agoDo you leave your door unlocked because locks have been demonstrated to be easily broken? The first rule of security is that security is all about layers. Also, I sent a copy of your comment to Phil @ Apple, I think he's going to drop all the DRM restrictions on iOS binaries and release Apple's private keys used for signing iOS apps after reading your comment.
- jerf 14y agoMany private keys have remained private. (So far as we know... and note here I'm talking about private as in asymmetric public/private such as can be used for signing, not "keys that were meant to be private but got leaked".) In fact, I'd observe the Microsoft private key wasn't even leaked. Another private key was created that due to flaws in MD5 allow someone with vast, vast resources to figure out how to forge another one that would be accepted. One can equally read this as proof that the system is pretty strong, if it took government-level resources to attack a known-weak system that I would imagine won't be in the next signing standard. We can not assume that private keys will leak. We can not even assemble an argument that the probability is high, which is because it isn't.
- wmil 14y agoI don't see how. Flame managed to create signed malware with an MD5 prefix attack... but MD5 had known problems for over 10 years. And Flame is widely thought to have been produced by a government intelligence service -- it still takes massive talent and CPU time to do something like that. I'm not aware of any MS private key ever being leaked or cracked. There will be weaknesses in specific UEFI implementations, but I don't think they'll be able to produce anything general purpose.
- nl 14y agoI think the point was that Flame was signed with a Microsoft key. It's true that key shouldn't have been trusted for what it was used for, and that the MD5 attack basically elevated the rights of the key, but the parent's point isn't 100% wrong (nor is it 100% right..)
- sseveran 14y agoFlame used a prefix collision attack that had not been seen before. The concept was demonstrated a couple of years ago but the attack itself was novel. http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/ http://arstechnica.com/security/2012/06/flame-crypto-breakth...
- beagle3 14y agoWhile that's true, what enabled Flame to use that to sign code was a chain-of-trust mistake as nl pointed above -- and there's no guarantee that such chain-of-trust mistakes will not happen in the future.
- sseveran 14y agoChain of trusts always require the chain to be secure. In fact there will undoubtedly be future chain of trust attacks on certificates.
- wmil 14y agoIf the boot loader is required to show a splash screen the user will still get clear evidence that something strange is going on.
- ajross 14y agoA technical user, sure. But that's an awfully big step down in security guarantees: "Hardened, secure boot with guaranteed validity and authentication at each step." to "Wait, did we install Ubuntu on this box?"
- jdhopeunique 14y agoAlso it could have the effect of associating the Ubuntu splash screen with malware in the users mind. Given that many users associate a black linux commandline prompt with malicious hackers, this might cement in their minds that linux is bad.
- beagle3 14y agoThey should have a splash screen saying: "Now booting Ubuntu Linux. If one of the next screens says "Welcome to Microsoft Windows", your system is probably infested with malware.
- Someone 14y agoWho says "the user" will see that splash screen? Firstly, I think typical users will switch on their PC, then look elsewhere for a minute or so. Secondly, there is the case of having a nefarious sysadmin (Internet cafe, hotel, etc) A splash screen that required acknowledgment would work for case #1, but would be annoying, too.
- deleted 14y ago[deleted]
- Havoc 14y agoYes it does seem like a decidedly half-baked plan. All the hassle and none of the benefits.