7 ms·

Linux Foundation Secure Boot System Released

125 points by onosendai 14y ago

patrickaljord 14y ago
cache: http://webcache.googleusercontent.com/search?q=cache:http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/&hl=en&tbo=d&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...
sergiotapia 14y ago
I'm not 100% sure what this means. I remember hearing a lot of rabble rabble a few months back about Microsoft placing some roadblocks on hardware that would make it more difficult to install Linux on machines. Does this mean this is now a non-issue? Thanks in advance.
- mjg59 14y ago
  It's been a non-issue for a couple of months - the Linux Foundation implementation is an alternative approach, but there's already a freely-available signed bootloader that distributions can use.
  - slug 14y ago
    I disagree that's a non-issue. Recently a relative's 10+ year old computer broke down. After buying a new one, until I was able to boot from an external linux usb/CD disk and be able to boot linux from the hard disk after installation, took several trips to the BIOS to change a myriad of UEFI settings, which is completely non-trivial to someone that just wants to try a live CD.
- keeperofdakeys 14y ago
  With secureboot enabled (the default on windows 8 certified hardware, or pretty much all x86 consumer platforms), you can't simply insert a linux installer or livedisk. You have to either play around with keys, or disable secureboot in the UEFI configuration. If your OS doesn't allow arbitrary code to be run on the raw machine (so a chain of trust on executables), microsoft provides a signing service. This is a problem for linux, due to the way it allows any code to run privileged. This is a problem because if a generic linux kernel was signed, it could be used to bypass secureboot (since it allows you to run any code, and it would be trusted). Some distros are looking at disabling all these features, so that their distro image can be signed. This would disable all third-party modules, and disallow other features (that most people probably don't use anyway). This specific post is about an a key management program, that allows a user to install their own keys, so they can sign their own linux image. A simpler option allows you to put your machine in another mode that disables secureboot. Like the UEFI configuration option, this is a roadblock to new users, who want something to "just work". So unfortunately yes, it's still an issue.
kunai 14y ago
Doesn't matter if it's signed code. I still turned off Secure Boot on my T430. It is rare that I have ever gotten malware, much less any that execute code at boot. Boot-sector virii died off in the late 90s. Make no doubt about it; this is just another monopolistic implementation of restrictive technology by Microsoft.
- shadowfox 14y ago
  > any that execute code at boot. Boot-sector virii died off in the late 90 Are you sure? It looked like rootkits/bootkits are still pretty rampant?
  - sophacles 14y ago
    The security world is as driven by fashion and old-concepts-with-new-names as the rest of the software industry. The general treadmill is basically 1. Look at this bug! lolz,pwnd 2. Script kiddie tools made around it and lots of variants are popular 3. Security improves as prevention tools get better 4. 0day experts look in other systems. (aka goto 1 with a different subsystem argument). 5. Eventually, as techniques in all subsystems improve, the original area of exploration is again the lowest hanging fruit, with a slightly different guise. For example - SQL injection is just a variant of the old pipe injection attack (also, pipe injection is coming back a bit, because newer programmers haven't seen it, and older programmers have forgotten about it). Another example you're starting to see more of again: IP stack attacks - as ip is being offloaded into the NIC you're starting to see a revival of "lets see what we can do to the ip stack" but this time it's in the card itself. (Actually there is some really cool stuff going on here...) So yeah, boot time attacks are pretty common and in these days, but not necessarily in the main boot path, but in cards with firmware, especially those that have DMA. Additionally with tools like metasploit, you can keep around a huge toolkit of root-kits and so on, so if a system is vulnerable to known boot-time exploits, you can use them even if you'd forgotten them.
    - asdfs 14y ago
      Can you elaborate on "pipe injection"? I can't find references to the term after brief searching, and I'm curious.
xuhu 14y ago
Meanwhile Ubuntu's Wubi-based installer is rendered useless since the Windows 8 bootloader won't load it (nor will it load anything except Windows apparently if SecureBoot is enabled).
- mjg59 14y ago
  I don't think Wubi's ever worked with UEFI systems.
RexRollman 14y ago
Great news but this entire situation is still a cluster-fuck.
- Qantourisc 14y ago
  Yep ... and I feel like we are feeding the trolls.
martinced 14y ago
Amazing. An article about "Secure Boot" and they transmit... A MD5 of the file. The nineties called, they want their MD5 back.
- mrb 14y ago
  Yep. They should have instead published SHA2/SHA3 hashes.
- keeperofdakeys 14y ago
  I'm pretty sure the md5 hash is just to test the integrity, to make sure it isn't corrupt. Due to all the other trust issues (no HTTPS), the insecure aspects of md5 don't really matter.
erhardm 14y ago
I don't feel safe at all. The same way goverments could ask Microsoft to have a builtin backdoor for Windows, they could ask for a signed rootkit.
- keeperofdakeys 14y ago
  Microsoft is actually in quite an interesting situation here. Although they have a lot of power in deciding what they sign, they also have a large obligation due to their now monopoly position. It's these situations that antitrust laws can start applying, but Microsoft would have to abuse their position for that to happen.
- gizmo686 14y ago
  They probably don't even have to ask. They could A) steal MS's signing key. B) Find a security flaw in an already signed bootloader. C) Ask MS to sign a non-rootkit bootloader with a subtle security flaw.

125 points by onosendai 14y ago

cache: http://webcache.googleusercontent.com/search?q=cache:http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/&hl=en&tbo=d&strip=1 http://webcache.googleusercontent.com/search?q=cache:http://...

sergiotapia 14y ago

I'm not 100% sure what this means. I remember hearing a lot of rabble rabble a few months back about Microsoft placing some roadblocks on hardware that would make it more difficult to install Linux on machines. Does this mean this is now a non-issue? Thanks in advance.

mjg59 14y ago
It's been a non-issue for a couple of months - the Linux Foundation implementation is an alternative approach, but there's already a freely-available signed bootloader that distributions can use.
- slug 14y ago
  I disagree that's a non-issue. Recently a relative's 10+ year old computer broke down. After buying a new one, until I was able to boot from an external linux usb/CD disk and be able to boot linux from the hard disk after installation, took several trips to the BIOS to change a myriad of UEFI settings, which is completely non-trivial to someone that just wants to try a live CD.
keeperofdakeys 14y ago
With secureboot enabled (the default on windows 8 certified hardware, or pretty much all x86 consumer platforms), you can't simply insert a linux installer or livedisk. You have to either play around with keys, or disable secureboot in the UEFI configuration. If your OS doesn't allow arbitrary code to be run on the raw machine (so a chain of trust on executables), microsoft provides a signing service. This is a problem for linux, due to the way it allows any code to run privileged. This is a problem because if a generic linux kernel was signed, it could be used to bypass secureboot (since it allows you to run any code, and it would be trusted). Some distros are looking at disabling all these features, so that their distro image can be signed. This would disable all third-party modules, and disallow other features (that most people probably don't use anyway). This specific post is about an a key management program, that allows a user to install their own keys, so they can sign their own linux image. A simpler option allows you to put your machine in another mode that disables secureboot. Like the UEFI configuration option, this is a roadblock to new users, who want something to "just work". So unfortunately yes, it's still an issue.

kunai 14y ago

Doesn't matter if it's signed code. I still turned off Secure Boot on my T430. It is rare that I have ever gotten malware, much less any that execute code at boot. Boot-sector virii died off in the late 90s. Make no doubt about it; this is just another monopolistic implementation of restrictive technology by Microsoft.

shadowfox 14y ago
> any that execute code at boot. Boot-sector virii died off in the late 90 Are you sure? It looked like rootkits/bootkits are still pretty rampant?
- sophacles 14y ago
  The security world is as driven by fashion and old-concepts-with-new-names as the rest of the software industry. The general treadmill is basically 1. Look at this bug! lolz,pwnd 2. Script kiddie tools made around it and lots of variants are popular 3. Security improves as prevention tools get better 4. 0day experts look in other systems. (aka goto 1 with a different subsystem argument). 5. Eventually, as techniques in all subsystems improve, the original area of exploration is again the lowest hanging fruit, with a slightly different guise. For example - SQL injection is just a variant of the old pipe injection attack (also, pipe injection is coming back a bit, because newer programmers haven't seen it, and older programmers have forgotten about it). Another example you're starting to see more of again: IP stack attacks - as ip is being offloaded into the NIC you're starting to see a revival of "lets see what we can do to the ip stack" but this time it's in the card itself. (Actually there is some really cool stuff going on here...) So yeah, boot time attacks are pretty common and in these days, but not necessarily in the main boot path, but in cards with firmware, especially those that have DMA. Additionally with tools like metasploit, you can keep around a huge toolkit of root-kits and so on, so if a system is vulnerable to known boot-time exploits, you can use them even if you'd forgotten them.
  - asdfs 14y ago
    Can you elaborate on "pipe injection"? I can't find references to the term after brief searching, and I'm curious.

xuhu 14y ago

Meanwhile Ubuntu's Wubi-based installer is rendered useless since the Windows 8 bootloader won't load it (nor will it load anything except Windows apparently if SecureBoot is enabled).

mjg59 14y ago
I don't think Wubi's ever worked with UEFI systems.

RexRollman 14y ago

Great news but this entire situation is still a cluster-fuck.

Qantourisc 14y ago
Yep ... and I feel like we are feeding the trolls.

martinced 14y ago

Amazing. An article about "Secure Boot" and they transmit... A MD5 of the file. The nineties called, they want their MD5 back.

mrb 14y ago
Yep. They should have instead published SHA2/SHA3 hashes.
keeperofdakeys 14y ago
I'm pretty sure the md5 hash is just to test the integrity, to make sure it isn't corrupt. Due to all the other trust issues (no HTTPS), the insecure aspects of md5 don't really matter.

erhardm 14y ago

I don't feel safe at all. The same way goverments could ask Microsoft to have a builtin backdoor for Windows, they could ask for a signed rootkit.

keeperofdakeys 14y ago
Microsoft is actually in quite an interesting situation here. Although they have a lot of power in deciding what they sign, they also have a large obligation due to their now monopoly position. It's these situations that antitrust laws can start applying, but Microsoft would have to abuse their position for that to happen.
gizmo686 14y ago
They probably don't even have to ask. They could A) steal MS's signing key. B) Find a security flaw in an already signed bootloader. C) Ask MS to sign a non-rootkit bootloader with a subtle security flaw.