Securing Hardware with Coreboot

Table of Contents


A laptop is sent in for an audit. It was reported that this particular laptop was exhibiting some ‘odd’ behavior. ‘Odd behavior?’ one might think. Just a user who is doing it wrong. Minutes later, an Operating System (OS) with a famous logo has been booted and the investigation begins.

The misbehavior is that at any given time on a website an advertisement is displayed. Imagine a blank HTML page with the imprint of ‘Hello World’ and right beneath it a width banner for whatever sells best in this moment. ‘Odd’, one might think. The banner cannot be found in the actual source code. But a solution is at hand: The installation of an Anti-Virus (AV) software.

One AV-Scan later, a nasty malware, an abbreviation for malicious software, is found. Software that appends to any given website an advertisement banner. The AV Software suggests to do what it can do best; removing the malware. It seems that the oddness has been taken care of.

The computer is left running for another day, as routine dictates. On the next day, the weirdness is about to start over: The malware has returned. Without the Anti-Virus noticing, the malware was re-installed on the Windows laptop. Another AV-Scan tells the same story. Again, the AV Software deletes the malware. Was this maybe a malfunction of the AV Software?

The malware is found again. Again a banner for some dirty websites is concatenated into the ‘Hello World’ page of the web browser. This time, another AV Software is installed. As its predecessor, it unveils the malware and erases its traces from the surface of the hard disk. Yet only, to be found once more later. One might change to another AV product of the many solutions the market offers, in the hope one of them might deal with it correctly. However, why should anyone trust a compromised system anyway? The auditor decides to do a fresh installation of the Windows laptop.

Some time later, the laptop has a new installation of Windows, including the newest security patches. The odds are now against the malware, one might think. For another night, the computer keeps running and the malware seems to be gone. But what is this? The next day, the malware returns. Did the malware just re-install itself?

A conclusion comes to mind: Has some hardware related component been infected? Parts of the computer will be replaced, the hard drive, the Network Interface Card (NIC) until only the motherboard remains. Fortunately, the ROM Chip in which the BIOS, the Basic Input and Output System, lives can be exchanged. The BIOS is responsible to initialize the hardware. A new ROM Chip was purchased over the vendor. The same procedure is conducted once more, re-installation of the OS and another day that passes. This time, no advertisement shows up. For once, no new malware installation is unveiled. It has been defeated!

Why do we trust a system?

In a plot like chapter one (introduction), we are not confronted with malware, but with a type of software that is named ‘rootkit’, or ‘bootkit’. A rootkit is a piece of software that acts maliciously and compromises a system in a way that it changes execution flow. Allowing arbitrary code to be executed and changing the behavior of the affected system to the authors biding. While the plot from chapter one was imaginary, one could only imagine how a researcher has found the ‘Mebromi rootkit’56 1.

With the rise of computers, they become ubiquitous in our environment. We entrust them everyday with more and more tasks that are crucial for our society as a whole. However, with this degree of importance, how much of the systems we are using can be considered to be trustworthy? In the plot of chapter one, it was an obvious situation.

Over the last 20 years, computer systems have become so complex that no one can handle their complexity. Software and hardware alike have grown in this intricacy likewise. While software can be reviewed, hardware cannot. Many vendors of hardware7[8] also do not allow reviews. Systems are sold as black boxes and hardware vendors just implement them to their system. These are many areas in which a rootkit can nest.

Different researches[15][62][96][97] have shown that attacks on firmware components are quite likely. Some time ago, a researcher presented an obnoxious type of rootkit named: ‘badBIOS’[9]. A rootkit that is supposed to infect a system using ultrasonic sound. While many experts[10] remain doubtful about it, researchers from the Fraunhofer Institute have shown in their paper: ‘On Covert Acoustical Mesh Networks In Air’[11] that using ultrasonic sound is a valid communications channel. The security researcher Robert Graham analyzed the composed feature of the ‘badBIOS’ and concluded[12] that it is plausible.

With the development of a proof of concept (POC) rootkit ‘LightEater’[15], Corey Kallenberg and Xeno Kovah demonstrated how plausible rootkits in BIOS[16] are. ‘LightEater’ allowed the extracting of GPG keys, even when a secure OS like Tails was running.

Backdoor-Capabilities in Hardware

Figure 1.1: Backdoor via an Inverter[[13], Page 7, Figure 1]

It is possible that a computer with all security patches still might be compromised, with changes[[13][14] deep inside the hardware, beyond detection from any software. This might be possible when it is embedded into the firmware[17][18] or in the hardware itself. Firmware is hardware specific software. The word firmware is composed out of the words ‘firm’ and ‘software’.

With the NICSSH[19 page 4], an attack was demonstrated that aims at functions in modern NICs. This attack allows to execute a minimal SSH Server within the NIC. This way, an attacker can access the hardware via the network traffic. He can then snoop all of the network traffic. While the NIC might not hold enough resources for longer traffic dumps, another device can be utilized to bypass this obstacle. Hardware, such as the graphic card, will be used in order to store the network traffic in the memory of the GPU. The CPU is almost entirely uninvolved.

Apart from potential backdoors, Intel itself does provide backdoor type capabilities within its shipped hardware. The ‘Intel Anti-Theft Technology’[20] allows to control modern processors remotely, even when the OS is turned off. It might be disabled, but even a corporation like Intel is not always capable of securing their products appropriately.

Once hardware itself becomes compromised, it is almost impossible to detect the compromised component. Figure 1.1 shows a hardware Trojan altering the behavior of logic gates that are composed out of CMOS. On the left side of figure 1.1, there is the supposed inverter and on the right side a compromised one. The compromised gate will be placed within critical components, components like a Random Number Generator (RND). This would lead to the result that the RND produces numbers of predictable manner for an attacker.[13 Page 10]

Other methods to compromise hardware exist: the Hardware Description Language (HDL)[21 page 42], for example, responsible for the designs of specific components. Another option could be the implementation of shadowing components[22] during the development process of hardware.

Figure 1.2: Cost of Security [23]

At the end of the day, this comes down to one essential aspect: The costs of time and money. The main question shows the value one tries to protect and how much would it cost to undermine this. In figure 1.2 [23], we need to look for the right spot to address security, else we will not have a reasonable degree of security. But the question that needs to be raised is, what do we want to protect? What is our asset? 2

Modelling a Threat

To find flaws, we will need to create a model of the asset we consider worth protecting. To rephrase the situation from chapter one: How could the laptop have been protected? A useful instrument to make sense of risks for an asset is the usage of a Threat Model.

Threat Model

A Threat Model(TM) is an abstract representation of systems to find flaws. Adam Shostack has developed a general approach to TMs at Microsoft:

Everyone threat models. Many people do it out of frustration in line at the airport, sneaking out of the house or into a bar. At the airport, you might idly consider how to sneak something through security, even if you have no intent to do so. Sneaking in or out of someplace, you worry about who might catch you. When you speed down the highway, you work with an implicit threat model where the main threat is the police, who you probably think are lurking behind a billboard or overpass. Threats of road obstructions, deer, or rain might play into your model as well. When you threat model, you usually use two types of models. There’s a model of what you’re building, and there’s a model of the threats (what can go wrong). [...] (Adam Shostack[3] page 24)

A TM can thus be summarized as follows: ‘whatever can go wrong’. This question is important to any devised system. How does it handle failure, misbehavior or maliciously formatted inputs. Because this is a model, we will illustrate our system in the most simple fashion. In our model, we will take a look at our current system and try to think about potentials threats, aspects that can go wrong. Once we have all reasonable possibilities, we advance the model. Extending the model with more details that were considered as a threat before. One characteristic of TM needs considering:

You’re never done threat modeling. (Adam Shostack [3] page 403)

It is important to set boundaries to a TM or else it will never be finished. Therefore, we will set the scope of our TM to aspects that are in our control. We are going to do the same as Adam Shostack has explained, but instead of thinking what might be lurking behind a billboard, we will devise a simple model that will represent a laptop to allow us to unveil potential flaws within our system. The approach for this is the following:

$$\textrm{Modelling} \rightarrow \textrm{Identify potential attack surfaces} \rightarrow \textrm{Research about Threats} \rightarrow \textrm{Revise Model}$$

Model of a Laptop

We will start with a simple mode for the TM that relies on aspects of the described problem from chapter one. We had a laptop that consisted of an OS and running a web browser. The OS was re-installed and at some point, the hardware was considered a problem. For this TM, we will use a layered model approach:

Figure 2.1: Threat Model of a Laptop

We will elucidate the TM first. Our TM consists of three areas to begin with:

Since users nowadays only rely on a web browser to do their work, we will focus on web browser. The level of security has changed drastically in the recent years for web browser, as research[24] has shown. Most things happen in the web or ’cloud’3. Web browsers are fast moving environments, with a lot of focus. Their code is open source, well matured and many audits were performed on it.

Projects like Firefox[25] or Chromium[26] are not free from flaws. One partially interesting contest is the ’Pwn2Own’, hosted by the Zero Day Initiative (ZDI)[27], the security team of HP. ’Pwn2Own’ is an abbreviation for ’Powning to Own’, where the word ’Powning ’is an expression used in the Hacker community for successfully gained privileges (like root or Administrator) on a system. The goal of a participant in this event is to take control of a fully patched device. ZDI provides varying laptops with distinct OSs, each running separate web browsers. When a participant can gain higher access through code execution on a laptop, hence win the devices and money. This year’s winner was Richard Zhu[29]:

He used an out-of-bounds (OOB) write in the browser followed by an integer overflow in the Windows kernel.[..] (Dustin Childs [28])

The attack aimed at a misbehavior[28] in the memory management of Firefox. The relevant point is that the attacker has gained more privileges on a system by utilizing an integer underflow within the OS kernel. Once something goes wrong inside of the kernel, it eventually leads the code to being executed with the highest permission. Flaws like this are, once found, fixed quickly by both browser vendors and OS vendors. However, this needs to be considered in the TM as well.

Why does this matter? Simply put: Imagine browsing a website and clicking on a link. This act would allow an attacker to execute code. This code would exploit the OS kernel to gain higher privileges. At this point, the attacker could do anything with the device.

An example[30] of such an attack can be seen when looking at the case of Ahmed Mansoor, a lawyer for human rights in United Arab Emirates, who received an SMS with links to a website. The content of the SMS should have lead to ’secrets’ being disclosed on the website. He did not know the SMS original address and did not open those websites. Instead, he contacted Citizen Lab to analyze and tell him what would have happened if he had open the link:

Had he done so, Citizen Lab says, his iPhone 6 would have been “jailbroken”, meaning unauthorised software could have been installed.

’Once infected, Mansoor’s phone would have become a digital spy in his pocket, capable of employing his iPhone’s camera and microphone to snoop on activity in the vicinity of the device, recording his WhatsApp and Viber calls, logging messages sent in mobile chat apps, and tracking his movements,’ said Citizen Lab [..] (BBC[30])

This means, this is not just a hypothetical thought; high profile targets are already being attacked4. This represents an extreme example, but how much could a common laptop be affected by flaws?

In 2015, media attention focused on the laptops of Lenovo. CVE-2015-2077 was unleashed and revealed that all their laptops shipped with a ’backdoor’ by default. The backdoor was a default SSL Certificate that allows to intercept all traffic, hence any type of security mechanism implemented by vendors of OS and web browsers became invalid. This flaw was called ’Superfish’[31].

How was it possible that a vendor could ship such a component on laptops? The Original Equipment Manufacturer (OEM) or the vendors of motherboards, control what is on the hardware before it is shipped to any client. OEM are the producers of hardware. They produce the hardware we are using and composing them of different components. Therefor it is their design what softwares is runs on the laptop. This includes the OS.

However, similar to the ’Superfish’ problem, other problems have been reported. Even worse, laptops were ’bricked’[32] by the OS because vendors had shipped faulty firmware.

Enhance of the TM

We have seen and identified potential attack surfaces. But OS consists of tools and components that could be compromised as the ’Superfish’ flaws have shown. At this point, we need to consider that the OS is not just a simple layer, but a system composed of different layers. The OS kernel was attacked by Zed to gain further access. This aspect needs to be addressed in the TM.

The kernel of an OS, like all other tools one needs to run an application, have undergone massive changes in the last decade. While not all of them are open, the defense mechanisms that are implemented are impressive. With the release of Windows 10, Microsoft had reworked the kernel and took an effort to increase security[33].

A kernel and/or OS can be ’hardened’[34][35], meaning to reduce its surface against attacks or increase the resilience of a system to withstand potential flaws. Many of the flaws demonstrated in the ZDI event might have been mitigated with a hardened OS and kernel. This raises another concern: How is security hardware before any OS is started and what does the computer do when it is starting? Participially with the knowledge that vendors, who are in control of the software that is shipped to customers, are building in backdoors.


We are going to debate hardware related technologies. Vendors changed the default firmware from BIOS to UEFI. It is the default technology for modern hardware and will be required by Windows 10. UEFI[36] is an acronym for Unified Embedded Firmware Interface. It is the successor to BIOS and a deviate from EFI. Most modern devices will be shipped with UEFI by default.


Figure 2.2: Overview EFI[37]

The BIOS standard is limited in its capability to utilize modern processor features. With the development of the Itanium processor, Intel had to devise a solution to address this shortcoming. The initial proposal was called ’Intel Boot Initiative’. To reflect the effort more objectively, it was renamed[38, Page 11] to Embedded Firmware Interface (EFI)[36]. It is intended to permit an OS to interact with the underlying firmware of the hardware, as displayed in figure 2.2. We are going to intertwine this model with the Threat Model from figure 2.1 later.

EFI provides an environment to execute high-level languages like C[38, Page 11], instead of native assembler. A modularized concept was introduced to allow extending. EFI is able to handle 32 Bit and/or 64 Bit Instructions and can therefore address all of its memory.

Due to lack of compatibility with existing x86 processors and the fact that the Itanium processors were only obtainable for server systems, they did not succeed[39, page 2] on the market. With AMD’s release of a 64-Bit x86 processor, that respected the compatibility to existing x86 applications, the x86 did remain the predominant processor architecture on the market.

Intel tried to push EFI as a standard to replace BIOS on the classic x86 market, but ceased the development of it in favor of UEFI. EFI remains in the ownership of Intel, but many aspects of the EFI Standards are adapted by UEFI. EFI was designed for the Itanium processor only but altered later to other processor architecture as well. The UEFI Forum[36] adapted the EFI and developed it further[38, page30].


Before we take a look into the UEFI architecture in-depth, we will make an introspective to the BIOS and how it boots a system. While UEFI has become the default firmware on modern computers, it has actually not replaced BIOS. Instead, BIOS became a legacy system of UEFI. This way, UEFI ensures compatibility with OSs like MSDOS.

The notion ’BIOS’ was defined by Gary Kildall in 1975[40]. His idea was quite simple: Having a pieces of firmware that initializes the hardware. Once all hardware is initialized, the firmware ceases and an OS takes over. Gary Kildall devised this for his development of the CP/MOS, later also known as ’DOS BIOs’ or ’IBMBIO.COM’. With DOS taking the lead in the market, latter expression was more established. The first version of a BIOS had no graphical interface. Only in case of an error, some type of informative message was shown, sometimes with an error noise.

In the 1990s, a need for visual surfaces was addressed for the first time. BIOS Software was extended with a GUI to allow consumers to change configurations. After some time, more features were ’added’ to the BIOS. However, this only showed downsides of it. BIOS cannot be extended. It has strong limitations: BIOS can only address up to 1 MB of memory or storage due to the fixation to the ’Real Mode’ of a processor.

Operating Modes

The ’Real Mode’ mentioned earlier in the chapter requires some explanation. Processors have different ’Operating Modes’[43, page 11]. These ’Operating Modes’ are states in which the processor acts with different capabilities. These modes are historically grown. With each generation of processors, new feature sets were added. To ensure backwards compatibility, the feature sets were packed with the different modes, so that older software would remain working with a previously introduced set of capabilities.

Figure 2.3: Operation Modes of a x86_64 Processor

As a researcher[41] has shown in his work, it is possible to run software developed forty years ago on modern processors. Windows has disabled the 16-Bit subsystem with the release of 64-Bit based Windows OSes[42]. However, the processors remain capable of doing so. A program that can set the right CPU flags can again be run within the 16-Bit mode of the CPU.

  1. Real Mode

  2. Protected Mode

  3. Virtual-8086 Mode

  4. System Management Mode

  5. Long Mode

Real Mode

The ’Real Mode’[43] resembles the primitive state of an Intel 8088 processor. This mode can only address up to 1MB of memory and storage. BIOS is limited to this mode because it was developed for the processor with this feature at that time.

Protected Mode

Newer models of Intel’s processors were extended with a ’Protected Mode’. With the expansion of features ,the processors became more powerful and were able to address more than 1MB of memory. Not all programs were able to handle this bigger address space. Within the ’Protected Mode’, the memory was segregated into segments.

Virtual-8086 Mode

With the usage of the ’Protected Mode’, another problem was arising, the need for programs to run within a ’Real Mode’ environment, particularly within a DOS program. For this, Intel introduced the ’Virtual-8086 Mode’, which allows a program to execute as if it was running in ’Real Mode’. This allows once more backwards compatibility.

System Management Mode

The SMM (System Management Mode) is used in different ways. Its purpose is to control hardware related subsystems e.g power management. It varies in the fact that it is not a normal operating mode as the mode introduced before. It owns many privileges which makes this subsystem interesting for an attacker. SMM can access memory beyond the control of an OS and modify memory without its consensus. Even OS like OpenBSD with specific hardening can be subverted.[50]

Long Mode

This mode was introduced by AMD[43] to allow the usage of 64-Bit addressing and instructions, whereas Intel was attempting to restart the process architectures with the Intanium Platform, which failed. AMD just extended the instruction set of the x86 processor.

Boot process

When a processor is powered on, it is going to initialize some things that are integrated into the silicium. For example, it will reset all the data in the registers and set them to the default values. The CPU will be set up in the ’Real Mode’.

Once the processor is finished with the initializing phase, it is going to load instructions from storages. This first loadable instruction is located in the ’Reset Vector’[44, page 113]. Basically, the ’Reset Vector’ is a pointer or memory address in which the processor can check for further instructions. In most cases, a simple jmp instruction is located here that will point to some address within the storage.

A code block from an original BIOS can be seen in code listing 2.1. One should notice that at this stage of the boot process it is only possible to execute assembler code; because the processor was rested or powered we deal with a ’cold boot’. This means we do not have any hardware configured like the main memory. Hence, paradigms like a Stack or Heap are not in place yet.

F000:FFF0 jmp far ptr bootblock_start
F000:FFAA bootblock_start:
FF00:FFAA   jmp exec_jmp_table
F000:A040 exec_jmp_table:
F000:A040 _CPU_early_init
F000:A043 ;-----------------------------------------------------
F000:A043 _j2:
F000:A043  jmp _goto_j3
......... ; Other jump table entries
F000:A08B _j26:
F000:A08B  jmp setup+stack
F000:A08E ;-----------------------------------------------------
F000:A08E _j27:
F000:A08E  call near ptr copy_decomp_block
F000:A091  call sub_F000_A440
F000:A094  call sub_F000_A273
F000:A097  call sub_F000_A2EE
F000:A09A  retn

Listing 2.1: Bootblock of an AMI BIOS[44, page 163].

In this code block we have a good example of a limitation. The first line is the Reset Vector, that leads to the execution of code of the ’bootblock’. The bootblock is the first code from the BIOS in which the processor sets up some basic. The code also includes the last function in the line: copy_decomp_block. This block will decompress the code.

Why does it need to decompress anything? Simple, the ’Real Mode’ is limited to one MB of space, but BIOS has grown with time. To program more effectively, the developer of BIOS came along with some ’hacks’. For instance, they implemented some of the registers of a processor with a Stack, allowing to make function calls in assembler. Another one of these ’hacks’ was the usage of the ’Unreal Mode’[45][46]. This mode allows to use up to 4GB of memory while reaming with the 16 Bit instruction set. These ’hacks’ should constitute the limitation of the BIOS and why there is a benefit of using UEFI.

mØ This will lead to the POST process, the ’power-on self-test’ in which all hardware that was found would be initialized. Some peripherals like NICs or the Embedded Controller (EC) need to load an OptionROM. Once this phase is done, BIOS will load the Boot loader of an OS.

Boot Loader

Once the hardware is initialized by BIOS, control will case to the next stage to invoke a ’bootloader. The boot loader has to setup the processor to allow the OS kernel to be loaded with long mode. At this point, we can see differences between UEFI and BIOS. In case a failure happens, UEFI can fall back to a shell and lead the user to resolve the problem. Therefore, having a boot loader within the ROM seems useful.

UEFI Architecture

Figure 2.4: Process of Booting UEFI[38, page 13]

The architecture of UEFI is formed out of a complex multistage boot process[38, page 249]. The image5 in figure 2.4 represents this process. The first row in figure 2.4, the row on the left side, is called ’SEC’ stage.

’SEC’ stands for Security. This stage belongs to the pre-EFI (PEI) phase and in this stage the platform specific code begins to execute. In short the system firmware will be initialized. Also, the registers of the processor will be configured as RAM. This act is named ’Cache as Ram’(CAR)[44, page 108] and is necessary to allow high-level language like C to be executed without initialized memory.

Once the SEC stage is finished, a dispatcher will be called that invokes the PEI phase. This stage can be seen on the second row from left in figure 2.4. The main memory will be initialized. Subsequently, the content of the CAR will be moved to the main memory. After the PEI stage is finished, another dispatcher will be invoked that leads to the transition into the Driver Execution Environment (DXE), seen in figure 2.4 in the third row from the left.

Within the DXE phase, a high-level code can be executed independent of the underlying platform. It sets up the code for SMM and when enabled, secure boot will be enforced. At this stage, features can be accessed. Hardware like the PCI Bus and OptionROM will be loaded. At this stage, most of the hardware should be accessible, including the network card and the EFI shell.

Once the DXE[49] phase is finished, UEFI will transit to the Boot Device Selection (BDS), as shown in the fourth row in the graph 2.4 from the left side. The BDS is a file from the DXE encapsulated. It will call an exit function of the DXE and remove every code besides the UEFI run time environment. At this point, the actual signature of the firmware is validated. Once done, it will call the boot loader from the OS and move to the Transient System Load (TSL).

In chapter Secure Boot, we will take a look at the ’Secure Boot’. The Unified EFI Forum releases an open source implementation called ’tianocore’[76]. It is the reference implementation of the UEFI standard.

Secure Boot

Figure 2.5: Overview about ’Secure Boot’[48, page 29]

The core feature of UEFI is ’Secure Boot’ (SE). SE allows the usage of a cryptographic signature to verify underlying components, like the firmware. The signature will be checked against a Public Key Infrastructure (PKI).

As part of the PKI, a Platform Key (PK) will be generated. The PK acts as the root of trust. OEMs will be in control of the PK. Additionally, all keys that will be used later are validated against the PK.

Another set of keys will be generated, the ’Key Exchange Key’ (KEK). This set of keys will be used to validate the signature database (db) or the revoke signature database (dbx).

The KEKs will be validated from the PK. The KEK protects the db/dbx from alteration. The db contains a list of signatures of programs (DXE driver and apps) that are allowed to be executed.

Figure 2.6: UEFI Key Store[49, page 30]

There is a difference between ’Secure Boot’ provided by UEFI and Windows’ ’Secure Boot’[52]. Windows’ relies on the UEFI one. Because of this decency, Microsoft has developed guidelines to ensure that Windows Secure Boot works with the UEFI Secure Boot. As can be seen in figure 2.5, the underlying layer validates the upper one.

Flaws in UEFI and Secure Boot

Because UEFI is responsible for the first instruction that is being executed, we will need to ensure that this is secure. Yet, UEFI is full of flaws. For once UEFI is backwards compatible, this implies that a user can use a ’legacy modus’[96]. This legacy modus is similar to the classic BIOS. This is necessary to ensure compatibilities to old OSs like DOS. But instead of replacing BIOS, UEFI extends BIOS with a more complex solution.

Further issues are that UEFI does not implement[51] any type of security mechanism like Address Space Layout Randomization (ASLR) or setting a NX bit for the memory. Each code that will be executed has the high privilege on predictable positions within memory. While Intel provides papers on how to implement UEFI securely, many vendors do not seem to care.

Figure 2.7: Software Supply Chain Breakdown

While there is an open source implementation (as can be read in chapter UEFI) of the UEFI standard, fixes within this implementation are not pushed directly to the OEMs, except Apple. As shown in figure 2.7, an update from the CPU vendor to the OEM needs to pass the Institute for Business Value (IBVs), the Original Design Manufacturer (ODM), and then eventually the OEM. This leads to the problem that fixes within the original UEFI code of ’tianocore’ might never reach the end-user. Even when updates occur, the end-users would have to update the software on their own.6

In the end, UEFI introduces a huge complexity with its standard, even hardware vendors have problems complying to. While the design might be fine, most of the flaws lie in implementation. Furthermore, many vulnerabilities have been existing for years within the reference implementation of the UEFI without being addressed. Vendors tend to not go along with recommendations in regards to security from Intel. UEFI forces them to take a trade-off between being secure or fast booting and the vendors tend to take latter one[96].

Thought needs been given to the UEFI Secure Boot, considering that every vendor implements it in their own matter, not always complied to the requirements Windows has for its Secure Boot. As attacks have shown, the SPI Flash Chip remained alterable, allowing an attacker to alter content of the SPI Flash Chip. This allowed to corrupt[48, page 65] the PK and put the UEFI into ’setup mode’. Once it is in setup mode, Secure Boot is disabled and an arbitrary driver can be installed. Aside from this issue, Microsoft has its own questionable pragmatics[53] in regards to the usage of Secure Boot.

Revised Threat Mode

Now is the time to revise the TM we created and build up on it. Before we do this, we will take a look on some aspects research has shown. We will take the model from figure 2.2 .

Figure 2.8: Revised Threat Model

In figure 2.8, an improved version of the TM can be seen.

When we take a look at what type of research is out there, we will notice that as we go closer to the hardware, the fewer resources we get. Web browser, OS and Kernels have been hardened for the last decade to withstand many different types of attacks. They are universally more exposed to users and therefore being attacked more often. Special attacks were made and resilience is in place.

While flaws exist in all parts of this model, one should consider the lifetime of a flaw and how quickly they are solved. Flaws that are found in web browser are fixed within days. But more importantly, they are distributed to the users in almost the same time.[24, page 268]

Flaws in Operating Systems, can live up to 5[54] or 7[55] years. Some are fixed within days, some take half a year. It depends on the vendors. But OSes are fixing their flaws in general. Those fixes are distributed in releasable time to the users. Not every user is installing them; however, this situation has improved over the years. (Compared to Windows XP time).

Flaws in hardware persist even longer. The Meltdown/Spectre[64][65] vulnerability has remained undetected for 20 years[56] and even months after the disclosure, not all processors have been addressed. There are no processors that are not affected and it might take some years before processors are released without the flaws. Intel has an interesting way to address these flaws: They update a special firmware, called microcode[57], that mitigate the flaws on the hardware.

Similar can be said about UEFI/BIOS related firmware. Even when flaws are unveiled, this does not imply that those flaws are fixed. OS and web browsers have developed strategies to patch effetely, in contrast to hardware and firmware[96]. Also, the User is responsible for installing updates for their firmware. But how many users do so is unknown. Flaws that are found and reported to Intel might lead to a ’fix’[59]. But these flaws are not distributed to the users, but to the OEMs and it is not certain that this vendor will release/push an update to the clients.

There is very little information about firmware related issues. We can expect that flaws are not patched or at least not communicated.


The main goal of a Threat Model is to find flaws within our asset. While we could keep Threat Modeling, we will stop to model now. To keep in reasonable costs(see figure 1.1)7. But how can we address found flaws? Considering the current model (figure 2.9) we can only address one aspect: The UEFI/BIOS layer. The firmware underneath the UEFI/BIOS layer is mandatory for the hardware to operate, since hardware itself cannot be changed.

Matrosov[61] has suggested (figure: 2.9) that the firmware is the weakest link in the current hardware, even with features like Secure Boot.

Figure 2.9: Attack Surface of Firmware[61, page 22

We come back to the question of the costs. How much one is willing to spend in order to attack someone and how much one does want to invest to avoid being attacked. Luckily, we can replace the obnoxious UEFI/BIOS with a proper solution: coreboot[96].

  1. Most security researchers do not disclose the way they found a rootkit.

  2. We should also ask what we want to protect and from whom? [return]
  3. That being said, most security lies within the ’cloud’ and therefore outside of the scope of this thesis.

  4. This is just an extreme example and we are not affected, because we’re using a x86_64 laptop and not an apple product. This should illustrate how wrong something can go.

  5. It seems like a mandatory demand that every document or talk on UEFI must include this image showing these various boot phases.

  6. The situation reminds strongly on the problem Android has with its software system.

  7. We could keep Threat Modeling, but it would exceed the scope of this thesis.