Slashdot Mirror
Linux Foundation's Secure Boot Pre-Bootloader Released
hypnosec writes "The Linux Foundation's UEFI Secure Boot pre-bootloader for independent Linux distros and software developers has finally been released. Announcing the release of the secure boot system James Bottomley noted that the signed pre-bootloader was delivered by Microsoft on February 6th. Bottomley has released two validated files: PreLoader.efi and HashTool.efi. Bottomley has also created a bootable mini-USB image that provides 'an EFI shell where the kernel should be and uses Gummiboot to boot.' Just last week the pre-bootloader had to be rewritten to accommodate booting of all versions of Linux."
This is great news for Linux distributions, and a small victory in the losing battle for openness.
But in the spirit of openness, hopefully bootloaders for NetBSD, OpenBSD, and FreeBSD will also be eventually signed.
Everyone should be able to install and run whatever they want on their own computers.
All the time Microsoft have control, they will always have control.
Why don't people LEARN from history from how they operate?
This will all go horribly wrong, mark my words.
And I still do not understand how Microsoft get to control this.
Seriously, when Microsoft is paid for the key and they own the key into our computers, we've lost. Simple solution: Avoid ARM-based machines as long as Microsoft requires that no way exists to disable Secure Boot. By buying into this shit, we're just setting ourselves up to be fucked in the ass by Microsoft. I can't say anything good about the Linux Foundation for playing ball with these assholes either. Pre-bootloader, my ass--more like pre-pre-boot-extra-complexity-nightmare, thanks to Microsoft. Having to use this would be a disgrace; that alone should be enough to get people to buy more compatible hardware (but won't be).
That sort of doesn't make sense, the kernel is in full control of the whole physical memory, and once you boot the kernel, it's perfectly free to recreate its state and that of all running processes.
Ezekiel 23:20
Microsoft surely knows that Secure Boot won't affect savvy nerds from converting to Linux. They also surely know that Linux is still growing organically, relying on word-of-mouth and firsthand try-before-you-buy experience.
You are seriously delusional. "Converting" to Linux is not, has never been and will never become a threat to Microsoft. Right now Microsoft is pressured on other fronts, such as desktop PC losing relevance, not being on the boat on mobile and not competing effectively in the tablet game.
You are trying to wage last decades battle. Microsoft does not feel threatened by Linux on the desktop *at* *all*. Get real. The threats to Microsoft do not come from conversions in the x86 space, the come from vertical players and mobile, like Chromebooks, tablets, smartphones.
Note how *all* of these emerging platforms have more restricted app models, and especially *boot* models. Microsoft is simply evolving their primary platform to match the features and security (from closed and semi-closed gardens) of the threatening platforms.
The threat to Microsofts desktop business is *not* Linux. Even though Linux has evolved in that space and on the surface appears to be able to go head-to-head, Microsoft Windows is still *much* more mature than any desktop Linux. Consider for instance group policies, restart manager, volume shadow service, various troubleshooting guides, shims for both application and device compatibility etc. The real threat is that the desktop become irrelevant.
If the desktop is perceived as less secure than an online counterpart, Microsoft will be losing. They *need* to ensure secure boot. It is not a anti-Linux move at all. You are flattering yourself. And being stupid.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
... why Microsoft is the gatekeeper for what OS's are allowed to boot on the computers I buy.
True. Except that it can be used to bypass secure boot:
1. Boot secure OS.
2. Hack it, get root.
3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use.
4. Trigger reboot.
5. Pwnage.
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for. The only way to prevent this is for the kernel to use TPM hardware to sign the boot image. As this isn't yet an option, it's debated if Secure Boot linux should also disable hibernation, in order to be strictly compliant, even though it introduces much user annoyance to provide protection against an attack that would be near-impossible for even the best hacker to pull off.
Nobody ever brings this up but me. Guess who else is in the UEFI group?
AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies
Only the State obtains its revenue by coercion. - Murray Rothbard
To quote Wikipedia "The board of directors includes representatives from eleven "Promoter" companies: AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies."
No its not just Microsoft.
Only the State obtains its revenue by coercion. - Murray Rothbard
In a sense, they do not own a piece of Dell. From what I understand, they contributed some dough as a loan and I have not heard they will have anyone on the board. Dell cannot live on the desktop market, in the server market they cannot ignore Linux.
This doesn't stop MS from using its usual bag of dirty tricks, but if Dell has any sense and balls, he'll keep MS away from actually running the business.
True. Except that it can be used to bypass secure boot:
1. Boot secure OS.
Easy, assuming Microsoft operating systems are defined as a "secure OS", which they are for purposes of secure boot, despite all evidence to the contrary.
2. Hack it, get root.
Easy, assuming a Microsoft OS again...
3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use.
No need to disable such. Once you're at the stage of "waking" into a hacked kernel to boot, you can just write a new image each reboot, becoming how you always boot from then on. In any case, the only real trick here, regardless of which way you decide to handle reboots, is writing a hibernate image and hacking the on-disk kernel in the image. Is this really any more difficult than hacking a kernel in memory? Indeed, isn't it easier?
4. Trigger reboot.
Yup... trivial... once you get past step 3, the machine is pwnt...
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for.
Anything that you can do, you can make a script-kiddie toolbox for. The person who makes the toolbox obviously has more impressive skills than a script-kiddie, but that's pretty much always the case. This is not the easiest hack in the world, but I would say calling this "near-impossible" is extreme hyperbole.
"Convictions are more dangerous enemies of truth than lies."
As I understood it, the reason for uefi was being able to boot from big harddisks, having prettier hardware-setting-screens, having a builtin network stack for remote maintenance, and so on. It is questionable whether it was necessary to specify pretty much a complete operating system including cli, just to run another OS, and the recent samsung brick fun, is a good hint that manufacturers will need a few years to iron even the bigger kinks out of their implementation, but uefi itself is in theory not without merits.
The reason for secure boot isn't bios-malware, but boot malware. There are a few of those around, as far as I know. The problem with boot-rootkits would be that they can play hypervisor to your OS, which hides them perfectly from software running under it. The idea with trusted boot, again as far as I understood, would be to have a trusted bootloader, which loads a trusted kernel, which in turn loads trusted drivers and trusted applications, the trust being conveyed by signatures.
Only... you have to start at the bottom, which is the bootloader, if you aim for such a chain of trust.
The problem is even if they "do their job" how much can they do? Microsoft has the advantage of motherboard makers coming to THEM to get a key. On the other hand the Linux Foundation would have to seek out Motherboard makers large and small and convince them to add their key. It's not do-able to get all of them to agree even with unlimited time and energy.
The issue is, what keys come with the motherboard. for now, Microsoft guaranteed. So, the obvious short term solution (although problems like everyone has mentioned) is to ask nicely to use one of the keys that is already going to be on the board. Just not a long term solution, but at lest it lets us continue to have the option of booting Linux in some form without bypassing the boot security (as some have described it: without having to prepare, using MB maker's inconsistent and buggy tools and methods ). And booting demo/live disks relies on not preparing the MB before booting (at least for a lot of uses for live CD's)
AB HOC POSSUM VIDERE DOMUM TUUM
True. Except that it can be used to bypass secure boot: 1. Boot secure OS. 2. Hack it, get root. 3. Write hibernate image to the drive containing your hacked kernel, which includes disabling of the code to delete the image after use. 4. Trigger reboot. 5. Pwnage.
OK, I get where you're coming from, but you fail to see that Secure Boot and TPM are completely pointless endeavors, and they're FULL of holes because the OSes are FULL of holes. If there's a mistake in the kernel code that allows a root level exploit to happen then it can simply be re-exploited each time you boot your system, see? No need to mess with the boot-up files. Even if your CPU is running encrypted instructions of signed programs once you find some data that triggers a buffer overflow, you can simply use return oriented programming to build the exploit. This means your exploit is built out of "op codes" of data that jump from one existing piece of signed and encrypted code to another -- You don't even need to know what the code is that's executing, you just log the changes in state the locations perform, and these become your (complex) operations with which to build the exploit. This already exists, it's not hypothetical. Return Oriented Programming is made out of existing code, even if it's signed and encrypted. SecureBoot is pointless so long as kernels have mistakes that allow unexpected stack smashing, or heap function pointer overwriting. There doesn't seem to be any way to prevent the mistakes, since your human race tends to make mistakes. SecurityTheaterBoot is a more apt. name for it.
Ah, but if the kernels could be written correctly -- with no mistakes -- then there would be no exploit vectors to exploit, and thus absolutely no reason for Secure Boot to exist. It's pointless from a security perspective, it serves primarily to make it harder for users to install alternate OSs. That's all. SecureBoot should be considered harmful and avoided if possible.
It'd take some very impressive skill to do that - it isn't something you could just make a script-kiddie toolbox for.
NO, that's just wrong. Do you even know what you're talking about? Yes, it takes more skill than a script-kiddie currently has, but it just takes one skilled hacker to crack the system and add the exploit to an exploit tool kit then the script-kiddie toolbox would contain the impressive exploit.
What? Exploits aren't impressive anymore once they've been automated? Gimme a break man. This happens all the time, it's HOW script kiddies even exist. Ugh, sorry, but your words reek of ignorance -- It's like you don't even comprehend what your words imply (by your logic script kiddies wouldn't exist).
The only way to prevent this is for the kernel to use TPM hardware to sign the boot image. As this isn't yet an option, it's debated if Secure Boot linux should also disable hibernation, in order to be strictly compliant, even though it introduces much user annoyance to provide protection against an attack that would be near-impossible for even the best hacker to pull off.
"Only" -- That word shouldn't be used lightly, because it tries hard to make you a fool, every time. What if we put Linux in the BIOS firmware. The PC turns on and is running Linux. Firmware can check its hash / fingerprint matches the install image on boot, like it does already, (even CMOS checksums for integrity), without requiring anyone to be in bed with a flawed PKI model run by Microsoft. If we simply give users an option in the BIOS boot menu that says: "Enable OS install on next boot", and it would flash part of the firmware with the /boot/ data. That would be TONS simpler than entering a long hex code that they're going to fuck up, and to bypass this unencrypted method of booting securely would require entering BIOS and changing a setting (or cracking BIOS security) -- Which is exactly the same as with Secure boot.
If the OS w