The Need for Secure BIOS

In 1981, the concept of the Basic Input/Output System (BIOS) and the concept of the Unified Extensible Firmware Interface (UEFI) were introduced. These concepts were farfetched then because at the time very few people perceived any security threats that could have infected BIOS. Three decades later, security researchers have identified vulnerabilities to servers and endpoints posed by BIOS.

NIST Publication 800-147B is aimed at the unauthorized modification of BIOS firmware through malware. Such guidance can help improve security and mitigate remote attacks, but it will not stop a dedicated attacker who may try to tamper with BIOS using unshackled physical access to respective servers.

BIOS is a de facto standard-defining firmware interface built into IBM-compatible PCs and servers. BIOS is the first software run when the system is turned on. Although BIOS has not been a primary target of attackers, recent low-level attacks on endpoint systems have created the perception that attackers can gain entry into the systems by going lower or putting in more effort to reach bare metal. Getting any closer to bare metal is as good as reaching BIOS.

In 1998, the Chernobyl, or Spacefiller, virus attempted to overwrite critical information and overwrite BIOS, such as NSA BIOS backdoor (DEITYBOUNCE) and the Mebromi rootkit. All of these attempted to reinsert malware into the BIOS that would continue to reinfect the system. Infected BIOS is more than a problem; it is a persistent attack. Even if an antivirus program detects and cleans the master boot record infection, after every system reboot, the infected BIOS payload will repeatedly overwrite the master boot record code. Developing antivirus code for BIOS is a challenge since any error within the antivirus solution will render the system unbootable.

A stronger, more secure BIOS is the foundation of computer and endpoint security — as well as greater trust within a computer system. Such protection can be found in UEFI.

Advent

Some describe UEFI as the complete reimagining of the computer boot environment. As BIOS is a solid piece of firmware, UEFI is a programmable software interface that resides on computer hardware and firmware. UEFI resides on the /EFI/directory in nonvolatile memory as opposed to the entire boot code sitting on the motherboard’s BIOS. Once the computer boots into UEFI, a set of instructions is carried out for POST to load the operating system. In the process, the UEFI specification defines boot and runtime services, protocols for communication between device drivers, services and extensions. Further flexibility is offered as UEFI can be used by almost every combination of 32- and 64-bit Intel and AMD chips. Each case is a matter of compiling the boot code for the target platform.

Security

So what makes UEFI more secure than BIOS? Among other features, UEFI’s specifications add a protocol known as a secure boot. The beauty lies in how the secure boot prevents device drivers and operating system loaders unless they are not signed with an acceptable digital signature. When the secure boot is enabled, it allows a public key commonly known as a platform key to be written to the firmware. When the secure boot is in “user mode,” the driver and loaders that are signed with the platform key can be loaded and ready for operation.

Critics describe secure boot as an attempt to remove a user’s ability to control the operating system of a computer. Distribution developers may not disclose the private key, making the boot loader a problem in secure boot. Amid some practical issues regarding key disclosure and key shipping, several Linux distributors have developed different implementations for secure boot. For example, shim is a pre-compiled, signed boot loader that allows users to individually trust keys provided by distributors. Essentially, we have witnessed the partial adoption of UEFI, such as functionality with certain customizations. This is all well and good, but is it entirely secure?

Attacks Against UEFI

At the recent Black Hat conference, a group of security researchers presented a series of exploits specifically implementing UEFI to compromise a secure boot. These exploits work because certain vendors do not protect the firmware at the required level, allowing attackers to modify the code responsible for invoking the secure boot. Once these exploits are targeted to modify the platform key, however, it needs to be executed in kernel mode, which limits the possibility of the attack to a certain extent.

The problem grows exponentially when attackers are able to execute the exploit in secure boot’s user mode, gaining permission to execute code on the trusted system’s device drivers, operating system and regular applications, such as Java and Microsoft Office.

Systems whose UEFI variable can be modified directly from the OS can be rendered unusable and easily exploited in cyberattacks where mass systems are impacted.

UEFI security features are designed to prevent bootkits from being installed. These bootkits hide inside the system loader and start before the actual OS can run. It is possible to modify a setup variable in certain implementations of UEFI that can bypass the secure boot feature. The affected computer will fail to start again in case the unprotected setup variable is set to “zero.” This is called a “brick” system. Recovering from such an attack would be difficult and time-consuming because it involves reprogramming the BIOS chip, which requires manual intervention and specialized equipment.

Conclusion

UEFI was originally designed to replace BIOS to standardize modern computer firmware through the usage of common framework and reference specifications to be used by original equipment manufacturers (OEMs) and BIOS vendors. However, practically, there can be significant differences in how UEFI is implemented across different computer manufacturers and may even vary across different products from the same vendor.

Investigating BIOS security issues has been difficult in the past due to cost and a need for specialized skills. However, with the advent of UEFI, more researchers are looking into and investigating the problems. Hopefully, over the next few years, the most obvious vulnerabilities will be identified and fixed.

I feel that despite these vendor implementation differences, secure boot is still a huge step forward and, in the future, its implementation should be tightly controlled with predetermined and monitored reference specifications governing OEMs’ system build process.