Ubuntu, Redhat, and other distros are compatible with secure boot.
I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing.
Linux is here to stay. Relax.
I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing.
Linux is here to stay. Relax.
Although I am a fan, for my own projects, of GPL and AGPL licenses, I do like the availability of commercial apps on Linux. I like Linux because it is a great development platform but I am less of a purist than I used to be concerning an occasional commercial app.
By way of example, the company where I work today produces a hypervisor for x86. We're nowhere near big enough to exert market pressure on someone the size of MS or the hardware manufacturers. When we recently added UEFI support to our product, we looked at support for UEFI secure boot as well. Some systems made key management easy (obvious bios options, etc.), but others made it impossible. Upon investigation, this mostly appears to be more due to apathy on the hardware vendors part than any conspiracy theory, but for an end user the distinction is unimportant. Today we can work-around this by using an MS-signed bootloader shim, but this reduces the security of the end solution (any ms-signed shim will boot, a third party owns the root keys). And, as I mentioned in my comment above, MS can change their policies at any time.
I haven't run into an x86 system yet that doesn't at least allow you to disable secure boot, but the trend towards more locked-down hardware in general (esp. in mobile) worries me due to the potential for anti-competitive behavior towards both commercial and open-source software from third parties.
I'm sure that some vendors will provide an option, so this will just likely be an extra thing to research before buying a new system.
256‽
How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known.
The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possible, but terrifying more complex to pull off. But that seems a lot more like a local, physical attack that's much less useful and more targeted than your ordinary viruses that install after executing inside your OS, where viruses seem to have no problems pulling off privilege escalation exploits to gain kernel access then. Plus you can easily block this and then lock down your BIOS already.
It really seems like Secure Boot is solving a problem almost no one ever had. I may well be misunderstanding the point, so please elaborate on how this is useful and absolutely prevents a class of attack that could not be done otherwise.
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...
http://www.computerworld.com/s/article/9217953/Rootkit_infec...
A snippet:
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 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
So the concern is that the virus is installed like any others on Windows; but then it keeps itself installed through the boot process reloading it. Thus it must intentionally damage any internal Windows protections that would try and check for it during its own startup. Which of course would be a cat and mouse game.
Okay then, what stops a theoretical TDL5 from using a Linux distro's signed kernel/bootloader to boot a little mini OS that then does the same thing TDL4 does now? (even if the Secure Boot Linux kernel locks out kernel driver access; maybe it uses a privilege escalation exploit to regain that access)
It would seem like the only way Windows could be absolutely certain that only its own code executed up to the completion of boot would be if Microsoft were the only company that could sign working boot code for a hardware device. The gains in security wouldn't be worth the loss of freedom.
So it is not entirely without precedent.
Then again, this did not touch the OS bootloader itself, strictly speaking and might not have been prevented by "Secure Boot". Also, once you're diddling with a devices firmware, you might as well tamper with "Secure Boot" as well and defang the checking of the bootloader or even make the firmware live-patch the bootloader...
So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
From http://www.linuxjournal.com/content/growing-role-uefi-secure...
>Malware developers have increased their attempts to attack the pre-boot environment because operating system and antivirus software vendors have hardened their code. Malware hidden in the firmware is virtually untraceable by the operating system, unless a search specifically targets malware within the firmware. UEFI Secure Boot assists with system firmware, driver and software validation
>Without UEFI Secure Boot, malware developers can more easily take advantage of several pre-boot attack points, including the system-embedded firmware itself, as well as the interval between the firmware initiation and the loading of the operating system
>Nevertheless, in a variety of implementations that have already reached the market, UEFI Secure Boot has proven to be a practical and useful tool for improving platform integrity and successfully defending the point of attack for a dangerous class of pre-operating system malware.
I'd say that there's a better than even chance that the NSA already has Microsoft's secure boot private key.
The NSA and the PRC will get their payloads signed with the appropriate keys. Everyone else will do something cheaper and simpler, like reading their target's gmail accounts.
> So, while I am by no means a security expert, I have been wondering the same thing. The entire "Secure Boot" stuff just seems like a lame excuse to allow vendors control over what operating systems you can boot on their devices.
Yes: http://mjg59.dreamwidth.org/20187.html [1]
[1]: It's worth noting that mjg59 is a big secure boot fan, and did most/all of the Linux implementation.
More importantly, why limit this to linux? It would be a lot harder to develop a new OS - just like Linus did - when you have to deal with secure boot.