FSF Does Want Secure Boot; They Just Want It Under User Control 210
Yesterday, we ran a story with the headline "Free Software Foundation Campaigning To Stop UEFI SecureBoot." It's more complicated than that, though, writes gnujoshua: "We want computer manufacturers to implement Secure Boot in a way that is secure. If a user can't disable Secure Boot and they are unable to sign their own software (e.g., bootloader, OS, etc), then we call that particular implementation 'Restricted Boot.' We don't want computer makers to implement Restricted Boot. We want them to implement Secure Boot and to provide a way for individuals to install a fully free OS on their computers. Many computer makers are implementing UEFI Secure Boot in this way, and we want to continue encouraging them to do so." The complete text of the statement they'd like people to sign reads: "We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems."
Re:So then they're fine with Windows 8 (Score:5, Informative)
The FSF has been knocking Apple over iOS since its release. http://www.fsf.org/blogs/community/why-free-software-and-apples-iphone-dont-mix [fsf.org]
Re:What problem does it solve? (Score:5, Informative)
Many viruses modify either the OS bootloader or low level drivers (SATA, PCI bus etc). By loading so early in the boot process they have full and unrestricted access to the entire machine, making them excellent and difficult to remove rootkits.
This isn't just a Windows problem either, all operating systems are vulnerable to the modification of core boot files.
Apple did not get a free pass (Score:4, Informative)
Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.
Well to be fair both the FSF and EFF have been heavily involved after Apple demonised their customers calling them criminals for for jailbreaking Apples Phones(not theirs). Ignoring the fact that those are *electronic* devices and Apple is nowhere near a monopoly (I now its not a good answer for apple users), but again the same groups are not just focused on Microsoft. As for the FSF a quick Google gives this http://www.defectivebydesign.org/blog/1256 [defectivebydesign.org], although the jailbreak DMCA exemption for the iPhone...and not the tablet, have been big news on most technology sites.
Re:Restricted Boot by definition insecure (Score:2, Informative)
The problem regarding the "Secure Boot"-key are a bit different:
Because they are built into the UEFI-firmware they cannot be easily replaced. You have to upgrade your firmware to get a new key. And then there is some kind of chicken&egg problem:
When the built-in key is compromised what should be updated first? The boot-loader (Signed with the non-compromised key) ? Or the key? If you replace the boot-loader first, the firmware refuses to load this boat-loader. And if you first replace the key, you have the same problem.
To replace the key and the boot-loader you have to disable "Secure Boot" in the firmware (Disabling by software is not allowed), then update the key (Means flashing a new version of the firmware) and the boot-loader and then reactivate "Secure Boot".
Now think of Average Joe or your grand mother and tell me how someone like them will accomplish this.
Re:What problem does it solve? (Score:3, Informative)
BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 [kaspersky.com] has a list of modern bootkits.
Re:What problem does it solve? (Score:2, Informative)
Wrong.
1. You can turn it off on x86 - not on ARM
and the biggy:
2, Windows can tell if it was booted in secure mode or legacy mode.
So basically you couldn't be more wrong. Congratulations.
Headline is disingenuous (Score:5, Informative)
Re:What happens when... (Score:4, Informative)
Just because you haven't seen one doesn't mean they aren't prevalent.
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 [chmag.in] [chmag.in]
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk] [theregister.co.uk]
http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com] [computerworld.com]
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 dataThe 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 routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products
The OEMs offered to add Red Hat and Ubuntu etc.'s keys but they refused since they didn't want to have an exclusive solution and neither did they want to be in the position of signing keys. If the Linux foundation stepped up, the OEMs will gladly add their master key to U