ITSEC researchers have demonstrated a proof-of-concept bootkit that circumvents the Windows 8 Unified Extensible Firmware Interface (UEFI). Do you think the UEFI platform will be a serious security hole for Windows 8? How should enterprises change their perception of UEFI?
Ask a Question
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email at firstname.lastname@example.org.
To answer this question, we need to look at the role of UEFI, which is a specification that defines a software interface between an operating system (OS) and platform firmware. It's a replacement for the aging BIOS (Basic Input/Output System) firmware interface, which is well over 30 years old. The main task of BIOS is to initialize all system peripherals as well as the CPU. Once these initialization steps are completed, it releases control to the first sector of the bootable hard drive, called the Master Boot Record.
UEFI works quite differently. It does not rely on a boot sector; instead, it has a boot manager, which is a firmware policy engine that is in charge of loading the OS loader and all necessary drivers. The boot configuration is controlled by a set of global nonvolatile random-access memory (NVRAM) variables, including boot variables that indicate the paths to the loaders. Together, these provide a standard environment for booting an OS and running pre-boot applications. They also give better protection during the system startup process to prevent low-level malware such as rootkits from loading.
However, Italian security consultants ITSEC developed a UEFI boot loader that overwrites the legitimate Windows 8 UEFI bootloader and intercepts the loading of the Windows 8 kernel. This bootkit then disables the security controls used by Windows, including Kernel Patch Protection and Driver Signature Enforcement, to prevent the loading of unsigned drivers.
This circumvention of UEFI security is not just confined to Windows-based machines. UEFI is also used on Mac and Linux machines, so UEFI bootkits could easily target those OSes too. Also, bootloaders and bootkits were previously developed in assembly language, but with UEFI, they can be written using the easier and more widely adopted C programming language. This means more hackers will have the skills to develop bootkits and a larger user base to target.
What the ITSEC bootkit didn't do was circumvent UEFI security with the secure boot option enabled. The UEFI 2.2 specification includes a protocol known as secure boot, which prevents the loading of drivers or OS loaders that are not signed with an acceptable digital signature during the boot process. When secure boot is enabled, it is initially placed in setup mode, which allows a public key known as the platform key (PK) to be written to the firmware. Once the key is written, secure boot enters user mode, where only drivers and loaders signed with the platform key can be loaded by the firmware. This security check prevents an unsigned bootloader, such as the one developed by ITSEC, from loading.
For UEFI to provide true system startup protection, secure boot needs to be enabled. The only real downside of enabling secure boot is that it prevents all unauthorized OSes from running, including authorized systems that have been modified without being reapproved, which is often the case with open source systems. On a Windows-based network, secure boot should certainly be enabled and physical access to important systems should always be tightly controlled.
This was first published in February 2013