Posted
by
Soulskill
on Wednesday November 21, 2012 @05:18AM
from the threatening-to-become-post-bootloader dept.

hypnosec writes "The Linux Foundation's plans for releasing a signed pre-bootloader that will enable users to install Linux alongside Windows 8 systems with UEFI have been reportedly delayed. The Foundation proposed a signed pre-bootloader that will chain-load a bootloader which, in turn, will boot the desired operating system, thus keeping Linux installations for novice users as simple as it was before. Further, this particular component is meant for small-time Linux distros which otherwise wouldn't have the required expertise or resources to develop their own system to tackle the secure boot issue. This was going as per plans up until Linux kernel maintainer James Bottomley disclosed that he has been having rather bizarre experiences with Microsoft sysdev centre. Bottomley said, 'The first time I sent the loader through, it got stuck (it still is, actually). So I sent another one through after a week or so. That actually produced a download, which I've verified is signed (by the MS UEFI key) and works, but now the Microsoft sysdev people claim it was "improperly" signed and we have to wait for them to sort it out. I've pulled the binary apart, and I think the problem is that it's not signed with a LF [Linux Foundation] specific key, it's signed by a generic one rooted in the UEFI key. I'm not sure how long it will take MS to get their act together but I'm hoping its only a few days."Update: 11/21 14:22 GMT by U L: See the Original weblog post, and one interesting tidbit: Microsoft banned bootloaders licensed under the GPLv3 and "similar open source licenses."

It's a requirement as part of the Windows 8 hardware certification [microsoft.com] (applies not just to laptops and desktops, but to anything that the manufacturer wants to put the 'works with Windows 8' logo on, e.g. motherboards) that:
a) You be able to disable secure boot
b) You be able to enter your own keys into secure boot (either through adding them to the existing keychain, or wiping the keychain and adding keys)

Here's the relevant legalese from MS:

Mandatory. On non-ARM systems, the platform MUST implement the ability for a physically present user to select between two Secure Boot modes in firmware setup: "Custom" and "Standard". Custom Mode allows for more flexibility as specified in the following:
It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. This may be implemented by simply providing the option to clear all Secure Boot databases (PK, KEK, db, dbx), which puts the system into setup mode.

But that fact is inconvenient for those that support this slow intrusion into control of our hardware, so they will conveniently neglect to mention it (or the fact that this concession meant to spur adoption will almost certainly disappear once secure boot is fully entrenched)

Why is MS the one signing the bootloader in the first place? Shouldn't there be a neutral root authority like there is for any other certificate in the world? To make Linux developers ask Microsoft to sign their bootloaders sounds like a very clear conflict of interest.

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

Windows 8 was tested and found to be invulnerable [thenextweb.com] to about 85% of all previous Windows 7 malware. That means there's about 15% of old malware that can infect the new hotness. Depends on your perspective for the precise phrasing, but 'huge chunk' is not completely false.

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows.

Secure Boot was designed to block malware from successfully inserting itself into the boot chain to bypass OS security measures, and that's it. Beyond that it's up to the OS to block malware from running in ring 0 or ring 3, which comes down to AV scanning, code signing, and any privilege escalation exploits abused by malware. Secure Boot closes off one important vector for malware, not all of them.

What people really want is that their running code is verified to be running the way it is supposed to be. This requires formal proofs of code operation - which is notoriously difficult (and impossible to do generally with arbitrary software). SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor. SecureBoot can however make the lives of ordinary users difficult. For now, we have the ability to use our own trust anchor, or none at all. Microsoft can't yet afford to block users from running all the non-SecureBoot OSes - as these include older Windows releases.

It's sad that so many Linux distributions and foundations are going along with this.

Yes they can and will. That is all a part of the 'forced upgrade' plan to wealth. Microsoft will do most anything to make running an old OS more painful so you will be forced to buy from them again and again. I listen to the trials and tribulations of my coworkers trying to keep their ageing xp machines running on a daily basis. One is forced by M$ to keep the machine off the net because M$ decided that his license (part of a larger sitewide license) is now counterfit. Its used for malware testing so it does not belong on the net in the first place, but restoring and re-patching it every time it is used is a royal pain.

What people really want is that their running code is verified to be running the way it is supposed to be

And to do that, you need to know that all code running in the system has not been compromised. Starting with the boot-loader. if the boot loader is compromised, then ALL bets are off - you can't be sure that whatever hardware/software interrogation method you are using isn't being lied to something intercepting it at a lower level.

SecureBoot does not give that, it only attests the code image *started* as the one it was supposed to be, according to the trust anchor..

Secure boot can give that, if the code image checks the signatures of the drivers and the kernel it loads and the kernel can check the signatures of the executables it runs and not load anything else that is not signed. Lets say you set up such a system today, you can be sure after 1 year that the same binaries are loading and have not been replaced with malicious ones. Even if malware was loaded into memory at runtime, cleanup will just involve a reboot + replacing any drivers, executables, kernel etc that fail the signature check(ignoring changes to data i.e).

No, once malware has run you have to assume the worst; that software has been compromised and verifies false signatures. If you had a system that never allowed new signers (all signatures built into the kernel) then you would be right, but it would be inflexible. Also you can't just include executables in your checks; anything that could be interpreted also needs verification.

No, it can not. SecureBoot verifies the code image was the one that was intended, *prior* to that code being run. SecureBoot can say nothing about what happens when that code runs. In particular, SecureBoot will not protect you from the code being modified or replaced once it is running, by design or (the typical case for security compromises) through the bugs that are rife in any non-trivial body of code. To make guarantees about the correct operation of code and be able to verify it is free of bugs that w

Secure Boot closes off one nowadays almost completely irrelevant vector for malware

Of course if that were really true then MS would look very silly for all the effort they've dumped into it. In fact, their efforts only really make sense once you redefine Linux and other alternative-to-Windows OSes as malware. When you consider that free software (especially operating systems, web browsers and office suites) have proven a far bigger threat to MS's bottom line than any or all real malware combined, the secure boot campaign starts to really make a lot of sense.

I'm not surprised if a chunk of malware still happens to work on the latest OS, especially through a normal BIOS which has no secure boot. Not all malware roots the system or replaces critical files and even if they did a legacy system has no way of knowing.

Even under UEFI, the secure boot would be responsible for ensuring the OS loader and firmware drivers were correctly signed before executing them. Assuming they were then it's not responsible for exploits which happen down the chain. I assume Windows 8

The free software and open source software advocates merely need to stop buying hardware dependent on and designed for proprietary operating systems. There are options that are becoming very popular. The major issue right now is there are a lot of people too cheap to realize the difference between a $400 POS laptop with Microsoft Windows which has higher specs and your typical higher quality laptops smaller companies are shipping with Linux. Even if the hardware

That's one sentence from paragraph 328 of the document detailing their crimes. Them demanding exclusion and degraded functionality for a perceived threat to their market presence is nothing new, it'd fit right in with th

As of now we know that Win8 is vulnerable to a huge chunk of malware designed for older versions of Windows. This "UEFI Secure Boot" does not prevent it at all. I suspected earlier that UEFI Secure Boot wasn't designed to make PCs more secure but rather to lock down PCs, so novice users trying to check out some Linux distribution will have tough time doing so. This fiasco makes me sure that this was the case and makes me wonder why antitrust authorities don't do anything about this. This is potentially more harmful than MSIE case after all.

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

Actually UEFI does prevent a huge amount of it, and most important all the worst stuff that was beyond the ability of AV software to get rid of. Remember all those fake anti-virus scams? They installed a rootkit that changed the low level SATA driver which is loaded very early in the boot process. UEFI prevents an OS modified in that way from booting and the Windows 8 recovery system can detect and fix it.

Signing of apps and signing of drivers is handled by completely different people; I would imagine that signing of boot loaders is another, new group. This may well be their very first submission, so things may not go exactly as planned.

Somehow, thay can sign town of apps and drivers on a regular basis, but signing teeny tiny code for FSF got screwed... It only validate, in my opinion, this whole secure boot shit was meant to give alternative OS a hard time.

Actually I'm generally not a Microsoft fan but I'd reserve judgement on this. Signing boot-loaders to be authorised by the hardware is likely to be a different procedure and done by different people to signing drivers. They probably have not done this often and when they have it will have been mostly with their own generic key. I can easily put this down to mistakes, and if they sort it out promptly I see no reason to put it down to ill will.

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

A lot of servers aren't 'proper' server hardware. Sometimes consumer-grade is good enough, espicially when it's so much cheaper you can have redundent everything. Think clusters.

Even more than that. If you have a UPS and the server is never switched off, then power supplies and fans tend to last for ever if they are of an even remotely reasonable quality. The thing that kills power supplies most is heat death from inadequate cooling, and tedundant powersupplies don't help much there since they will both be

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

Does that mean the user has to actually be present to press a key? That renders secure boot unuseable on remote-admined or unattended servers, the very place you would most want to have a secure boot chain.

So, instead of signing with a scrap key that vendors will ignore they signed essentially with the original one, so that this bootloader will work on any PC that follows the standard? This is so awesome I don't even know at what to laugh first.

I wish LF just released this bootloader and defuse all this "secure boot" crap. Of course they will play nice and allow Microsoft to save their face... Microsoft incompetence is just appalling. They will probably end up signing malware by accident at some point, but at least you won't be able to run Linux on your PC, so mission accomplished.

If they did now, M$ would replace the broken key and its gone.BUT, if they wait for the time when this secure boot crap really hits the market and THEN release this bootloader, M$ wont be able to revoke this key, as too many vendors allready included it and many would not go thru this crap again.

So it would be strategically wise to wait like 3 years and THEN release this one to essentially kill secure boot.

On ARM, in order to use the windows logo marketing crap (you know those stupid stickers all over that otherwise nice looking laptop you last bought), there can be NO way to disable sec boot. Manufactures will cave.

So, Yes. When they feel they can get away with it on x86 (no more winxp etc. out there), they will likely follow the path they ALREADY took with arm.

So, not paranoia on all of our part, but burying your head in the sand on yours.

MS has engaged in some of the most evil bus practices of any company (intentionally breaking standards so folks on wincrap have to use MS solutions for those components that should be inter-operable, stealing code, waiting out the victims money reserves in court, suing the victim back (if victim somehow was able to survive long enough to win in court, (if above failed) buying victim companies and dismantalling them, trying to sneak in fake error messages with code that detected running competitors products, senior folks like Bill G trying to steal from other senior folks while they lie in a hospital bed-- at the time, presumed to be dying, a really fucked up company. Now that apple is trying to be more evil than MS, MS seems to be doing its part to try to capture back the title of do only evil.

> Or just disable secure boot, which is amazingly easy to do in the first place. If a novice user can properly install Linux, that same novice user can be directed to disable this stupid function.

To repeat what I have said before: how well will that really work in practice?

You: "Hey, I need to boot my Linux USB drive on your computer, is that OK?"Friend: "Uh, sure, I guess."Friend: "Uh, it isn't working."You: "Oh, I need to go in to your bios and disable SecureBoot."Friend: "Duh, you aren't disabling any

Those theoretical friends have some serious trust issues, especially if they're not even willing to listen to the reason why it needs to be done or what it even "secures". I'm surprised he was even willing to boot a foreign OS in the first place.

It's not actually a monopoly, because MS doesn't have anywhere near a monopoly in the tablet market yet. Ergo, no antitrust stuff is going to kick in...it's no more a monopoly than Apple locking down iPads is.

That said, I think it's a clear sign MS _will_ lock down the hardware as much as they can, and the only reason they've refrained from doing that on x86/x64 _for now_ is that they _do_ have a monopoly on that platform so antitrust rules would kick in if they try.

Feel free to run your own PKI and get the root keys included by the vendors. The option has been seriously considered by some of the larger Linux players, but it is just too expensive to do. Note that getting the root key included was not considered to be the main obstacle, it was the "run your own PKI" bit which killed the idea.

That is also why this is not news. PKI is hard, all of the major SSL signature vendors except one have made really stupid mistakes already. It is no wonder that Microsoft messes up

The way of breaking that monopoly is to replace UEFI on machines with CoreBoot (http://www.coreboot.org/Welcome_to_coreboot). This still does not support enough hardware but given a bit of support from Linux friendly companies (e.g. Clevo, IBM etc) it could be done. To see CoreBoot in action have a look at the Samsung ChromeBook with CoreBoot (http://www.youtube.com/watch?v=RypqMqtTPs8).

Given the number of server side linux installs on x86 machines the PC manufacturers are not going to shoot themselves in the foot and not supply machines that linux can be (pre)installed on. They'll probably have a Windows compatable line and a Linux compatible line. At least for servers. For desktops and laptops things could get a bit tricky I suppose, but then I was under the impression all this secure boot crap could be switched off in the BIOS anyway?

As I understand it, UEFI is not a requirement for Win8, instead it's additional expenses for hardware manufacturers.I'm guessing very few machines will actually have UEFI. Just some of the more expensive business models.

AFAIK Windows 8 doesn't require UEFI, but the vendors are required to implement it in order to be able to use the "Designed for Windows 8" stickers. I think they're also required to enable it by default. x86 vendors can have an option in the BIOS to allow it to be turned off (I imagine the vendors who largely sell servers will do this whilst the cheap brands won't because implementing a "off" option would cost them a few pennies more in coding time). As I understand it, MS has mandated that ARM machines

Last I heard, Apple had clawed it's way back to the top in some fashion... maybe the most profitable PC vendor? Anyway, they are pretty big and successful. Do they have this sticker? I doubt it. I'm thinking that a bunch of stickers all over your product detracts from the styling. A PC covered in gaudy do-dads looks like shit next to a PC with nice clean styling.

Maybe you should wake up. You think everyone is just going to sit idly by and let Microsoft force every other OS out of the market on consumer PCs unless Microsoft says it's OK for them to exist there? You don't think any of the big names in computing are going to have a problem with this?

No one else sees the glaring legal issues here? No one thinks Microsoft could see the glaring legal issues there?

By all means, mod this down like my previous post. You people are crazy.

'When you get to this stage, you also have to certify that the binary " to be signed must not be licensed under GPLv3 or similar open source licenses". I assume the fear here is key disclosure but it's not at all clear (or indeed what "similar open source licences" actually are).'

"I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3 forces me to release my private signing keys?

No. The only time you would be required to release signing keys is if you conveyed GPLed software inside a User Product, and its hardware checked the software for a valid cryptographic signature before it would function. In that specific case, you would be required to provide anyone who owned the device, on demand, with the key to sign and install modified software on his device so that it will run. If each instance of the device uses a different key, then you need only give each purchaser the key for his instance."

Technically, yes, but the reason they don't want to is because if they did, they would be forced to distribute signing keys to everyone who ever installed that binary, which would sort of ruin the security of the system, as a rootkit developer could just grab a key too.

Why would Microsoft, which is not distributing the Linux bootloader, be worried about the Linux bootloader license?

You are correct in that the bootloader cannot be GPLv3, because the GPLv3 does not allowed the distribution of signed-binaries that cannot be recompiled from source and signed again...but the fact is, this has _nothing_ to do with MS, which cannot possible be required to do anything at all.

MS was handed something to sign, it signed it. If there are distribution limitations on the thing signed

It's "Tivoization [wikipedia.org]": GPL software that can be modified and compiled, but the intended hardware will refuse to run it unless the binary is cryptographically signed...and the hardware vendor holds the keys and isn't sharing.

GPL 2.0 had no protections against this particular end-run on the "anyone can modify, anyone can use" philosophy of Free Software. Tivo very cleverly used this loophole to "protect" their devices from "unauthorized" software modifications (i.e., they used Linux kernel and GNU userland, but

If the UEFI binary was GPLv3 (not GPL like in your title, GPL v1 and v2 are good), then anyone distributing the binary will have to release the signing key, which defeats the whole purpose of UEFI secure boot signing since it will allow malware creators to sign their own malicious bootloaders with the key.

So does that mean that the FSF is going to release a binary without source code? How ironic.

No, the Linux Foundation. And no, it doesn't mean they'll release a binary without source code - it just means that the binary presented for signing must not be licensed as GLPv3 (or similar, whatever that means).

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Since users have go through a warning message everytime before such a system is booted , it is noticed that it's Slashdot posters and moderators that are retarded and falling for all the FUD about secure boot.

why would there be a warning for running this (eventually to be) signed linux foundation bootloader?

maybe you were referring to switching uefi sec off to run _any_ bootloader. but this one would be as legit as any for the bios.

So the Linux Foundation, quite rightly, are trying to make available a signed bootloader which will then anyone boot whatever we want without having to disable secure boot - have I got that right? What stops someone monkeying around with the next level of abstraction?

Not exactly. It will require a physically present user to click though a warning message before booting the "next level of abstraction".

I know that new laptops shipping with Windows 8 preloaded have to allow the user to disable secure boot.

Now that some laptops are out there, does anyone know if disabling secure boot will still let you run Windows, ideally even after its partition has been resized? Or will the preinstalled Windows just refuse to boot if secure boot has been switched off?

Sounds like another anti-trust case. I will be putting Unbuntu on my next machine and if I can't do it I will be asking for my money back and getting pi, though I might getting a pi anyway as they are much cheaper than a 'nomal laptop / netook'.

Microsoft as gatekeeper to PC hardware is a non-starter. You can not have one company determine who will and will not use a PC. When I mean use I mean loading the operating system of the user's choice. That is using a computer, running the programs and operating system that the owner of the computer wants. One company determining how a user will use their computer best example of a monopoly.

It has been proven recently that the whole WinTel PC thing and the associated lock in is on its way out as UEFI Secure Boot would be as well. ARM and Linux is where everything appears to be heading. Look at all the Android tablets and phones, Chromebook, Raspberry Pi, Beagleboard etc. Even Apple is rumored to be looking at ARM for newer laptops and are throwing their own cores together.

MS has a hold on the PC strong enough to survive several years, even if their management insist on their current suicide style of doing business. They can make a lot of problems even if they fail, and they can be a huge problem if they somehow get their heads over their shoulders.

Even if MS assured everyone that cooperating was in its own long term best interest, and even if we all believed that, believing that they would actually cooperate is foolish. Have we not all heard of The Scorpion and the Frog?

MS can do all the lock-down they want on the hardware they make and sell. But for them to be in charge of locking down 3rd party hardware and software that I buy from other vendors is just nuts. Especially as the 800 lb gorilla in the room means that I will have almost no choice of vendors that don't restrict my use. I want my computer to be mine, not Microsoft's and not Apple's.