UEFI -- What's changed?
A year ago Matthew Garret made the following argument:
What's changed? A LOT!
Yesterday, Garrett explained:
The Register was covering the story from ITSec about its bootkit, which can run a Linux kernel on a Win8 box secured with UEFI.
The author even supplies a video demonstrating it in action:
Ubuntu has done a reversal of its plan to pay Microsoft for signing keys. It will be staying with Grub 2 for 12.04.2 and 12.10. After that it is anyone's guess.
http://www.zdnet.com/ubuntu-linux-ad...ch-7000004648/
As long as I can boot a Linux LiveCD and install Linux on a machine with UEFI I don't care about UEFI. IF I can't, then I will be purchasing a couple used dual or quad core laptops with the old BIOS in them so that when what I am using wears out I can fire up a replacement.
These are the facts:
...
Why is this a problem? Because there's no central certification authority for UEFI signing keys. Microsoft can require that hardware vendors include their keys. Their competition can't. A system that ships with Microsoft's signing keys and no others will be unable to perform secure boot of any operating system other than Microsoft's. No other vendor has the same position of power over the hardware vendors. Red Hat is unable to ensure that every OEM carries their signing key. Nor is Canonical. Nor is Nvidia, or AMD or any other PC component manufacturer. Microsoft's influence here is greater than even Intel's.
What does this mean for the end user? Microsoft claim that the customer is in control of their PC. That's true, if by "customer" they mean "hardware manufacturer". The end user is not guaranteed the ability to install extra signing keys in order to securely boot the operating system of their choice. The end user is not guaranteed the ability to disable this functionality. The end user is not guaranteed that their system will include the signing keys that would be required for them to swap their graphics card for one from another vendor, or replace their network card and still be able to netboot, or install a newer SATA controller and have it recognise their hard drive in the firmware. The end user is no longer in control of their PC.
...
The final irony? If the user has no control over the installed keys, the user has no way to indicate that they don't trust Microsoft products. They can prevent their system booting malware. They can prevent their system booting Red Hat, Ubuntu, FreeBSD, OS X or any other operating system. But they can't prevent their system from running Windows 8.
Microsoft's rebuttal is entirely factually accurate. But it's also misleading. The truth is that Microsoft's move removes control from the end user and places it in the hands of Microsoft and the hardware vendors. The truth is that it makes it more difficult to run anything other than Windows. The truth is that UEFI secure boot is a valuable and worthwhile feature that Microsoft are misusing to gain tighter control over the market. And the truth is that Microsoft haven't even attempted to argue otherwise.
- Windows 8 certification requires that hardware ship with UEFI secure boot enabled.
- Windows 8 certification does not require that the user be able to disable UEFI secure boot, and we've already been informed by hardware vendors that some hardware will not have this option.
- Windows 8 certification does not require that the system ship with any keys other than Microsoft's.
- A system that ships with UEFI secure boot enabled and only includes Microsoft's signing keys will only securely boot Microsoft operating systems.
...
Why is this a problem? Because there's no central certification authority for UEFI signing keys. Microsoft can require that hardware vendors include their keys. Their competition can't. A system that ships with Microsoft's signing keys and no others will be unable to perform secure boot of any operating system other than Microsoft's. No other vendor has the same position of power over the hardware vendors. Red Hat is unable to ensure that every OEM carries their signing key. Nor is Canonical. Nor is Nvidia, or AMD or any other PC component manufacturer. Microsoft's influence here is greater than even Intel's.
What does this mean for the end user? Microsoft claim that the customer is in control of their PC. That's true, if by "customer" they mean "hardware manufacturer". The end user is not guaranteed the ability to install extra signing keys in order to securely boot the operating system of their choice. The end user is not guaranteed the ability to disable this functionality. The end user is not guaranteed that their system will include the signing keys that would be required for them to swap their graphics card for one from another vendor, or replace their network card and still be able to netboot, or install a newer SATA controller and have it recognise their hard drive in the firmware. The end user is no longer in control of their PC.
...
The final irony? If the user has no control over the installed keys, the user has no way to indicate that they don't trust Microsoft products. They can prevent their system booting malware. They can prevent their system booting Red Hat, Ubuntu, FreeBSD, OS X or any other operating system. But they can't prevent their system from running Windows 8.
Microsoft's rebuttal is entirely factually accurate. But it's also misleading. The truth is that Microsoft's move removes control from the end user and places it in the hands of Microsoft and the hardware vendors. The truth is that it makes it more difficult to run anything other than Windows. The truth is that UEFI secure boot is a valuable and worthwhile feature that Microsoft are misusing to gain tighter control over the market. And the truth is that Microsoft haven't even attempted to argue otherwise.
Yesterday, Garrett explained:
The Register covered a story on a UEFI-based attack on Windows 8. It's actually covering this technical writeup, which is a discussion of a proof of concept implementation of an attack on the Windows 8 kernel from the firmware environment.
...
But both these cases have something in common: they rely on the ability to run arbitrary code in the firmware environment, and that's precisely the thing that UEFI Secure Boot prevents. A system with a correct implementation of Secure Boot isn't vulnerable to the described attacks, but it's fairly unsurprising that running UEFI without Secure Boot is vulnerable. UEFI on its own doesn't provide any additional security. You're as vulnerable to bootkits as you are with BIOS.
So this isn't really a story about a surprising vulnerability. It's a story about someone taking the logical step of implementing a bootkit on top of UEFI, which is what everyone should have been expecting all along. Computers that are configured to run arbitrary code will run arbitrary code, and if that arbitrary code happens to modify your kernel so your credit card details are automatically posted to pastebin, well, that's a plausible outcome.
...
But both these cases have something in common: they rely on the ability to run arbitrary code in the firmware environment, and that's precisely the thing that UEFI Secure Boot prevents. A system with a correct implementation of Secure Boot isn't vulnerable to the described attacks, but it's fairly unsurprising that running UEFI without Secure Boot is vulnerable. UEFI on its own doesn't provide any additional security. You're as vulnerable to bootkits as you are with BIOS.
So this isn't really a story about a surprising vulnerability. It's a story about someone taking the logical step of implementing a bootkit on top of UEFI, which is what everyone should have been expecting all along. Computers that are configured to run arbitrary code will run arbitrary code, and if that arbitrary code happens to modify your kernel so your credit card details are automatically posted to pastebin, well, that's a plausible outcome.
Conclusions
In the brief analysis we made we have seen that hitting an UEFI system is still a quite easy task. In our bootkit develop process, we have showed only a small subset of kernel patch modality. We can indeed hit Kernel in a lot of others way (hooking Block I/O protocol Read function for example). Furthermore, for an attacker, it would be easy with EFI to disable bootkit if a debugger is detected for example (task done by intercepting Load Options of Winload and Nt Kernel). Sky is the limit.We’ve also found that writing an EFI Bootkit is even a simpler task than writing a BIOS Bootkit. While a BIOS bootkit requires a very large knowledge of Assembly language and Intel x86 architecture, an EFI bootkit is much easier to be developed because with the UEFI framework everything is abstracted from machine.
...
What about Linux, Mac and other platforms?
As outlined by others security researcher (noteworthy is Marco Giuliani’s article on Wirenet, available here), OS X and Linux Trojans, viruses and security threats are more and more spreading because these kind of platforms are becoming more and more widespread. The technology described here is valid also in OS X and Linux platforms. OS X, started using UEFI since 2010. At the Black Hat 2012 Conference we have observed agreat example of EFI Bootkit designed for OS X. Theoretically we can write an EFI bootkit able to forge OS X Kernel easily, as it already happens on Windows.
In the brief analysis we made we have seen that hitting an UEFI system is still a quite easy task. In our bootkit develop process, we have showed only a small subset of kernel patch modality. We can indeed hit Kernel in a lot of others way (hooking Block I/O protocol Read function for example). Furthermore, for an attacker, it would be easy with EFI to disable bootkit if a debugger is detected for example (task done by intercepting Load Options of Winload and Nt Kernel). Sky is the limit.We’ve also found that writing an EFI Bootkit is even a simpler task than writing a BIOS Bootkit. While a BIOS bootkit requires a very large knowledge of Assembly language and Intel x86 architecture, an EFI bootkit is much easier to be developed because with the UEFI framework everything is abstracted from machine.
...
What about Linux, Mac and other platforms?
As outlined by others security researcher (noteworthy is Marco Giuliani’s article on Wirenet, available here), OS X and Linux Trojans, viruses and security threats are more and more spreading because these kind of platforms are becoming more and more widespread. The technology described here is valid also in OS X and Linux platforms. OS X, started using UEFI since 2010. At the Black Hat 2012 Conference we have observed agreat example of EFI Bootkit designed for OS X. Theoretically we can write an EFI bootkit able to forge OS X Kernel easily, as it already happens on Windows.
Ubuntu has done a reversal of its plan to pay Microsoft for signing keys. It will be staying with Grub 2 for 12.04.2 and 12.10. After that it is anyone's guess.
http://www.zdnet.com/ubuntu-linux-ad...ch-7000004648/
As long as I can boot a Linux LiveCD and install Linux on a machine with UEFI I don't care about UEFI. IF I can't, then I will be purchasing a couple used dual or quad core laptops with the old BIOS in them so that when what I am using wears out I can fire up a replacement.
Comment