The Linux Foundation's UEFI Secure Boot Pre-Bootloader Delayed

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."

Comments

Re:Present user test?

[jimicus]

Likely to be much less of an issue on proper server hardware; most server vendors know full well a significant amount of the hardware they shift will never run Windows.

Microsoft banned GPL in UEFI binaries ..

[dgharmon]

Microsoft has also banned any GNU GPLv3 licences for these binaries.

'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).'

Re:Microsoft banned GPL in UEFI binaries ..

[l3v1]

Nevermind, I looked around myself: http://www.gnu.org/licenses/gpl-faq.html#GiveUpKeys

It says:

"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."

Re:Not surprised at all

[rsmith-mac]

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.

Re:Not surprised at all

[recoiledsnake]

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.

If you(and others here) really want to educate yourself instead of spreading karmawhoring FUD, please read on.

Here are some references about boot malware which UEFI secure boot will prevent.

http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/

http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft

I recommend reading atleast the first link.

Here's one juicy bit:

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.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo

Re:Wtf?

[Anonymous Coward]

They are already doing this.

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.