Is Hardware More Secure Than Software?

Is Hardware More Secure than Software?

Lianying Zhao Carleton University David Lie University of Toronto

Abstract—Computer hardware is usually perceived as more secure than software. However, recent trends lead us to reexamine this belief. We draw attention to the “ﬁrmwarization” of hardware and argue for revisiting the role of hardware and software in systems security.

TRADITIONALLY, computer systems can be quick search on Google Scholar returns at least thought of as composed of two types of compo- 1,750 academic papers with the title containing nents: hardware and software. Hardware refers to both “hardware” and “security” as of the time the physical components that perform a fixed set of writing. While this is a conservative under- of operations. Software on the other hand, defines approximation of the actual number of such pa- logical components, instantiated as data and in- pers (as it only checks the title), and regardless structions, which can specify arbitrary sequences of whether these papers propose a larger role of hardware operations, as well as inputs to those of hardware in security, or seek to examine the operations. A function can be implemented using vulnerability of hardware to security attacks, the a various mixes of hardware and software compo- sheer number informally illustrates that the se- nents (or even entirely in hardware). The mix of curity community has a strong interest in the hardware and software can have implications on relationship between computer hardware and se- certain properties of the function implementation curity. Another recent trend is the implementation (e.g., performance or security). of hardware mechanisms to address well-known Hardware Security. Hardware has been deemed security problems. For instance, a survey [8] lists to be the safeguard for security-sensitive op- 21 hardware-based architectures to ensure control erations for decades. This is reflected in the flow integrity (CFI, the correct flow of execution longstanding use of hardware security modules of a program). This implies that there is an (HSMs, such as the tamper-evident/resistant IBM underlying belief that hardware implementations Cryptocards) for cryptoprocessing, as well as the correlate well with better security properties in more recent interest in securing sensitive tasks computing computing systems. with trusted computing technologies like Intel SGX and ARM TrustZone. The Perceived Security Benefits of In academia, hardware security has also at- Hardware tracted significant attention from researchers. A We begin by examining where this belief in the security benefits of hardware may have The final version of this article will appear in the special originated. Intuitively, one may assume that the issue Hardware-Assisted Security of IEEE Security & Privacy. This is the author’s copy created on June 27th, 2020. DOI: feeling of security may naturally stem from the 10.1109/MSEC.2020.2994827 c 2020 IEEE. possession and physical existence of hardware.

IEEE Security & Privacy, to appear (accepted: May 2020) Special Issue: Hardware-Assisted Security 1 Hardware switches provide visible assurance of done if hardware is compromised or defective—a operation integrity, e.g., a state is set and its state hardware switch in a circuit may be maliciously remains unambiguously obvious. Similarly, users changed from off to on, but not reprogrammed can be confident that they possess and are in to be something else substantially different. By control of information and capabilities inherent in contrast, software generally runs on a Turing- detachable devices like USB dongles and drives. complete execution engine (e.g., the CPU), which Hardware components on first examination, ap- can be programmed to do something far from the pear simpler and more restricted in function intended functionality of the original software. than many software components. Components, So if compromised or defective, software may like hard drives store data and little else, while intrinsically give an attacker access to the Turing- keyboards provide a means to input information complete environment where arbitrary functions and commands. Indeed, the physical nature of can be performed. hardware means that defects in hardware are not We define privilege as the ability to observe as easily fixed after they are shipped to customers, and control the operations of another component. driving hardware designers to be more conser- This definition has a subtle difference from the vative and thoughtful in their designs. All these software definition of privilege (i.e. kernel vs properties contribute to an overall feeling of better user) as higher-privilege software generally is security and assurance in hardware over software. capable of a super-set of operations over lower- However, if we set aside assumptions about privilege software. However, the privilege of the conscientiousness of hardware and software hardware over software is different in that hard- designers, as well as possible mental biases to- ware and software are not capable of the same set wards physical versus logical components, and of operations. Yet, where it is comparable is that instead focus on the functional properties that dis- the additional operations that privileged software tinguish hardware and software implementations has usually include the ability to control (i.e. from a security perspective, we can contemplate start, stop and interrupt), as well as observe (read two that appear to stand out: 1) immutability and and write) the execution state of unprivileged 2) privilege. software. In the same way, hardware making up We define immutability as the ability of a the execution engine of software, has the same function’s properties to resist being changed from ability to control and observe the state of any those in their original intended design. Being software it runs. physically implemented in circuits and transistors, Modern computers all share the layered con- hardware has an “intrinsic” immutability, to it— struction starting from the hardware/firmware, the functions implemented in hardware cannot be VM hypervisor, operating system (OS), to ap- simply changed by altering some bits in memory. plications (see Figure1). A hypervisor is secure If an attacker wants to modify the function of against the OS kernel, which in turn is secure hardware, they must physically change it, imply- against applications. Hardware sits at the most ing the need for physical access to the victim. privileged position in this stack, and as such is This is comforting, as physical changes have a naturally secured against vulnerabilities in and at- higher chance of being tamper-evident. tacks coming from the lower-privileged software Such immutability can also be considered a layers. benefit of the fact that hardware does not need to implement a “Turing machine”. Hardware has Hardware, Firmware, and Software an inherent bias towards the “Economy of Mech- So far we have discussed a high-level ab- anism” [10]—because hardware has a physical stract model of computing system implementa- existence, there is a penalty for extra or unused tion where all components are all either entirely functionality, so there is a strong incentive to hardware or software. However, as the reader may avoid it. Therefore, hardware logic often imple- have guessed, the view of computing systems pro- ments just enough functionality to execute pre- moted by this article is not so simple. There actu- scribed tasks without enabling arbitrary opera- ally, exists a third, hybrid, type of implementation tions. This naturally limits the damage that can be for computational functions called “firmware”.

2 IEEE Security & Privacy, to appear (accepted: May 2020) applies. Even in that case, the compromised hardware remains immutable, e.g., hardware Trojans APP1 APP2 APP3 ... APPn inserted by the designer or manufacturer usually cannot be removed by firmware/software. Privilege: Also previously defined, privilege Operating System indicates the ability of a higher-privileged com- Hypervisor ponent to observe and control the execution of a lower-privileged component. Because all software Firmware must execute on hardware, hardware inherently Microcode has higher-privilege than firmware or software.

. However, it is often the case that firmware exists . . on the hardware side of the hardware-software Immutable hardware interface, and as such has privileges over software such as the OS kernel or applications. Thus, we order privileges with hardware at the top, “Code” Perceived hardware firmware in the middle, and, finally, software at the bottom. Figure 1. The layered construction of a computing Efficiency: Efficiency defines how much per- device, and what is commonly considered as hard- formance an implementation provides as a func- ware. tion of some resource (electrical power for example). Hardware implementations are generally The term firmware has existed almost as long as more power efficient than software, and provide computer hardware has, first coined by Ascher better performance for similar power consump- Opler [4] in the 1960s. Firmware shares some tion. While both firmware and software are less properties with software, in that it is implemented efficient than pure hardware blocks, firmware of- as software instructions that execute on a general ten executes closer to the hardware, and may have purpose, Turing-complete hardware processor. access to special hardware functions or facilities To better understand hardware, firmware and that may make it more efficient than software. software, we compare the three using 4 proper- For example, CPU firmware (i.e. microcode) is ties: immutability, privilege, efficiency and cost, not affected by context switches or OS scheduling summarized in Table1. like regular application software. Immutability: As defined earlier, immutabil- Cost: Hardware in general has a fixed cost ity characterizes whether the functionality of a with each system, while the incremental cost of component can be altered. While the immutabil- deploying software for each system is nearly zero. ity of hardware is intrinsic, the immutability of As a result, systems that contain more specialized firmware and software is not, and typically must hardware generally cost more to produce, which be enforced by some other component (either translates into a higher cost for the end user to hardware or software). For example, the address purchase. This creates an intuitive trade-off that space of firmware typically is blocked from ac- nearly every computer engineer is aware of— cess by applications, and in many cases, even faster systems that use hardware accelerators cost the OS by either a hardware reference monitor, more. or some combination of hardware and software reference monitors. From this, we argue that only Property Hardware Firmware Software hardware is truly immutable, while firmware and Immutability software can be either intentionally mutable by Privilege Highest Middle Low certain components, or mutable as a result of Efficiency High Middle Low design or implementation flaws. Cost High Low Low We exclude supply chain attacks in our discussion, because when products are compromised be- Table 1. Comparison of properties. fore acquired by the user, immutability no longer

May/June 2020 3 The Role of Firmware teristics normally associated with software. As Given the comparison in Table1, one may hardware becomes increasingly complex, many of wonder why firmware was introduced in the first these complex features are actually implemented place, as it seems to be superior to neither hard- as firmware. ware nor software in any property. One strong Baumann has stated that the hardware is the reason for firmware, among others, is to main- new software [7], emphasizing the rapid and iter- tain interoperability across a variety of computer ative manner in which modern hardware features systems interfaces. are being implemented. Many modern hardware In short, interoperability means that different “features” are actually implemented as firmware, implementations of components can work with and they are often rolled out iteratively, i.e., SGX, each other because the components all adhere then SGX2. Rather than actually replacing the to a standard interface. However, implementing components, defects in hardware can be patched that interface using varying mixes of hardware by changing the firmware. These characteristics and software allows manufacturers to create dif- increasingly give hardware both the advantages ferent products at different points in the cost- (i.e. flexibility, upgradeability) and disadvantages efficiency spectrum. For example, all network (complexity, mutability) of software. cards perform essentially the same function, but It is not uncommon to consider hardware and more expensive faster network cards may contain firmware as a whole to be just hardware, as a variety of accelerators and off-load engines illustrated in Figure1. For instance, a blanket that allow faster packet processing with lower- statement such as “hardware-encrypted drives are power, and at the same time freeing up gen- more secure than software full-disk encryption” eral purpose compute cycles on the main CPU. does not fully acknowledge nuances such as the A similar example is specialized cryptographic fact that hardware encryption implementations function accelerators. In some cases, functions often contain software (firmware) components. that are not performance-sensitive can always be What is worse, devices traditionally perceived as implemented in firmware. As these variants do “dumb” (i.e., not Turing-complete) when enriched not affect the interface, they can be used inter- with firmware (i.e., introducing a general-purpose changeably without changing software or other processor) become Turing-complete, and if com- hardware components. promised, can perform functions never intended Yet another important advantage that firmware in the original design. One example is keyboards, provides is the ability to update or patch hard- as exemplified by an Apple keyboard turned into a ware either to provide enhanced features or ad- keystroke logger [5] using merely software tools. dress defects. A variety of consumer devices from webcams, to thermostats, to home routers How Firmwarized Hardware can Go have the majority of their high-level functionality Wrong implemented in firmware so that they can be updated in the field and bring more value to the When hardware functions are implemented end consumer. In fact, a key selling point for using firmware, the immutability of hardware is some smartphone models is the length of time impacted, weakening the security against attacks. that the vendor will continue to patch security Indeed, in this section, we will examine some vulnerabilities in the smartphone firmware. hardware security failures from the past and see how a common thread has emerged where at- Hardware firmwarization tackers unexpectedly modify functionalities im- A key pillar of the security of hardware is plemented in firmware. We will also show how its immutability to software, which holds most firmwarization and its security consequences are naturally when hardware is actually implemented prevalent across different computer components. as hardware. However, in recent years, what is In our discussion we focus on two aspects: the traditionally thought of as hardware—the CPU, vulnerability itself, which leads to firmware com- hard drives and various other peripherals, are promise for arbitrary code execution, and the increasingly taking on implementation charac- harm that the compromise causes. We include

4 IEEE Security & Privacy, to appear (accepted: May 2020) vulnerabilities that may reside in 1) the firmware trol of a computer by exploiting a vulnerability in code itself, e.g., buffer overflow, or 2) the environ- a Broadcom NetXtreme NIC. The vulnerability ment where the firmware runs, which improperly was located in the firmware handling the ASF enforces firmware privilege and enables lower- protocol, an obscure protocol intended for remote privilege software to compromise firmware. We administration. group vulnerabilities by the type of component it Video cards. Video cards also contain firmware affects, as shown in Figure2, which illustrates in a component called the Video BIOS (VBIOS) how firmware vulnerabilities have existed in a which is loaded and executed on the CPU much plethora of system components, as well as the the same way that the regular system BIOS is. broad range of time over which those vulnerabil- There have been attempts to tweak the VBIOS ities have been found. such as nvresolution [12] which added support for better resolutions with framebuffer drivers. Input/output Devices Video cards can be co-opted to execute mali- Computer peripherals, such as drives, key- cious code that can evade traditional malware de- boards, mice and printers are usually seen as too tection. The Graphics Processing Unit (GPU) and simple to be compromised and used for attack. video memory (VRAM) provide a full execution However, these devices have been increasingly environment for malware, and the shared memory offering more and more functionality, often im- with the CPU can allow for attacks. For example, plemented in firmware, which has led to vulner- in 2013 researchers implemented a GPU-based abilities. keylogger that peaked into the keyboard buffer Hard drives. Hard drives and solid-state drives that is normally managed by the CPU. (SSDs), normally viewed as simple block de- Other devices. A variety of devices interface with vices, actually contain quite a bit of firmware. systems over platform buses such as PCI and A recent analysis of the (in)security of to- USB. Devices for these buses implement generic, days Self-encrypting SSDs [6] discovered a but complex functionality, such as automatic de- software-only firmware reflashing attack on Cru- vice discovery and configuration and arbitration cial MX100/MX200 using some undocumented between different devices. This functionality, also vendor-specific commands (VSCs). This vulnera- usually implemented in firmware, has also been bility could allow an attacker to remotely1 and the source of a number of vulnerabilities. For stealthily intercept any data to/from the disk example, in 2006, Heasman explored the special without leaving traces on the host. Unlike regular role of PCI expansion ROM (e.g., the VBIOS), a malware, the malicious code resides in firmware, piece of program as part of the device firmware so even a full operating system re-installation that can be loaded by the system OS during would not remove such malware. In 2013, Zad- initialization. Heasman discussed [13] how a PCI dach et al. [3] already demonstrated that a stealth card’s expansion ROM can be reflashed by mali- backdoor could be installed by software on an off- cious software, due to lack of firmware signature the-shelf mechanical hard drive. Jeroen Domburg verification. The card can then be used to mount (a.k.a. sprite tm)” also found the same vulnera- various pre-boot attacks including subverting the bility independently in the same year. OS kernel when plugged into another computer. NICs. Aside from hard disks, network interface Similarly, the plethora of USB devices exists cards (NICs) are another front for firmware com- partially because the USB interface offers rich promise. Back in 2006/2007, in the so-called and flexible functionality. This is a double-edge Project Maux Mk.I, Triulzi demonstrated a partial sword as almost any type of devices can be proof-of-concept takeover of a Broadcom NIC emulated from a USB device, as opposed to only by modifying the firmware. In 2010, Duflot and storage in the case of SATA (before the OS Perez then expanded this attack to take full con- is compromised). Nohl et al. demonstrated the concept of BadUSB [14], where USB devices 1We use remotely here to mean that they do not need physical access, but may still need to perform a remote privilege escalation can be reprogrammed to attack the host they are on the local OS first. plugged into. As an example, they were able

May/June 2020 5 Processor

Microcode <2004>[9] <2017>

SSD/HDD Motherboard Video card <2008> Chipset: Intel ME [12] <2013> [13] <2013> <2009> [6] <2018> <2017>

BIOS/UEFI/SMM: NIC <2008> <2006> USB drive <2009> PCI(e) <2007> <2010> <2015> ... <2014>[14] Keyboard

<2009>[5]

Figure 2. Distribution of ﬁrmware across computer components. Grey area designates presence of ﬁrmware and years indicate when a software-only compromise was reported.

to reprogram a USB device to emulate another such as hard drives and Bluetooth/Wifi adapters one, such as a keyboard, which when plugged- are both less frequent and user-driven, and the in could send malicious keystrokes to the victim overriding advice for such updates is to apply machine. These vulnerabilities stem from the lack only when there is an apparent need to, resulting of signature verification for USB firmware. This in a lower application rate of firmware updates. means that malicious software on one machine can use USB devices as a vector for infecting CPU and Chipset other machines. For example, malware on one Chipset firmware. Excluding peripherals, older machine can corrupt the firmware of a webcam or PCs could be thought of as a CPU surrounded USB drive, which can then compromise the next by non-programmable parts on the motherboard. machine the device is plugged into. The lack of The only vulnerable software running on such firmware verification is widespread—Nohl et al. a system would be the code running on the find that out of 52 chip families and 33 actual CPU(s). However, this simplistic view of a com- devices only one chip family implemented any puter system no longer holds. For example, the form of defense. Intel Management Engine (ME) is a stand-alone These problems are further complicated by “computer” with its own OS, implemented in the fact that users in general pay less attention the chipset of client PCs. The Intel ME powers to patching and securing their peripherals than the Intel Active Management Technology (AMT) traditional software systems such as the main sys- suite of tools. When security vulnerabilities in tem OS and services. While most mainstream OS AMT and the ME came to light in 2017 (CVE- and application software offer automatic updates 2017-5689), it caused much alarm in the security that keep these systems patched against known community, as it simultaneously became known vulnerabilities, firmware updates for peripherals that both the ME and its associated security

6 IEEE Security & Privacy, to appear (accepted: May 2020) weaknesses might have been present since as programmable parts on a motherboard, contain early as 2008. complex functionality and are a host of mys- Part of Intel AMT is an application (trust- terious firmware that most users only have the let) running in the ME environment, which en- faintest awareness of. ables remote management of computers. This Host firmware. We refer to firmware that runs highly-sensitive functionality was implemented on the CPU (as opposed to other chips) as host in firmware, which could be overwritten and firmware. Compared to chipset firmware, the host subverted. An attacker who does this could gain firmware, known as the BIOS/UEFI, is also more control over a system remotely, regardless of what than just something that shows the bootsplash software safeguards are in place in the operating screen and initializes computer hardware. Even system. Moreover, once compromised, being in after system boot, an essential part of it still con- a hardware-like position in the system, the Intel tinues to run in the System Management Mode ME enjoyed unchecked privileges over the rest (SMM), which runs custom and highly privileged of the system, making it difficult to be sure software that provides critical low-level system that any malicious code is removed. Security functions, such as power management and system researchers have been actively studying the Intel hardware control. Because SMM code runs with ME since 2009. Tereshkin and Wojtczuk coined privileges higher than even the OS, it is a peren- the term ring -3 rootkits referring to the code they nial favorite for attacks. On early motherboards injected to the ME with a privilege higher than (pre-2006), SMM code could be simply corrupted any software and other firmware of the computer. by malicious kernel code because the BIOS failed The injection attack exploited a weakness in the to hide the SMRAM (where SMM code executes) memory reclaiming mechanism in Intel CPUs from regular/system software. In the SMRAM that allowed an improper memory remapping Control Register (SMRAMC), the D_OPEN bit that should have been disallowed. The memory controls whether the SMRAM is visible, and the reclaiming that enabled the attack was intended D_LOCK bit locks up the whole SMRAMC and to allow system software to remap DRAM that D_OPEN until the next reboot. D_LOCK was not collides with physical address ranges mapped to set by some motherboards. I/O devices. The original design of the memory reclaiming mechanism neglected to take into ac- While this was easily fixed on subsequent count proper access control, such as checking for motherboards, it was not the end of weaknesses memory used by the Intel ME. in the SMM firmware. SMM exploits have been Although Intel later fixed this remapping issue continually identified since 2008. Later compro- and encrypted the ME memory in an attempt mises consisted of failures to properly secure to prevent further compromise of the ME isola- SMM from various other seemingly unrelated tion, further vulnerabilities in the ME firmware mechanisms. For example, the memory reclaim- kernel (e.g., CVE-2017-5705,6,7) still lead to ing flaw used to compromise the Intel ME was firmware compromise that allowed arbitrary code also exploited to attack SMM. This allowed a ma- execution. Similar to the Intel ME, the Intel licious operating system to once again gain access IE (Innovation Engine) was introduced to the to SMRAM by using the reclaiming mechanism Lewisburg chipset in 2017. Unlike ME that is to remap the SMRAM region into an accessible restricted to only run firmware deployed by Intel, region of memory. IE is intended for OEM uses, i.e., potentially About a year later, another SMM compro- opening up the door for more chipset firmware mise was found via a cache poisoning attack. vulnerabilities. Normally, system software can configure the For brevity, we do not discuss other types of Memory-Type Range Registers (MTRRs) to con- chipset firmware, such as the Baseboard Man- trol which memory regions can be cached and agement Controller (BMC, similar to the Intel how. But SMRAM did not get treated differently. ME, part of server motherboards for decades). Then the attacker could just modify the “spilled” What these numerous examples demonstrate SMM code (copied to cache) without accessing is that chipsets, far from being simple non- SMRAM directly, which would get executed in

May/June 2020 7 SMM the next time and manipulate the actual more complex operations to support new hard- copy in SMRAM. To fix this issue, a new register ware features. An anonymous report [9] reverse- System Management Range Register (SMRR) engineered the microcode update mechanism. It was introduced, accessible only from SMM, that highlighted that even if only vendor-verified up- can configure SMRAM caching properties. dates are allowed, an attacker in control of this Unfortunately, the war in SMM did not end process can still choose to patch the microcode in there. Later in 2009, researchers found that a way that facilitates his attack. What is fortunate improperly written SMM code could invoke is that no recent CPUs are known to be vulnerable functions outside SMRAM, leading to poten- to such attacks [1]. tial arbitrary code execution in SMM. To prevent such callouts, another new control was added, i.e., the SMM_Code_Chk_En bit in Analysis of Firmware Vulnerabilities the MSR_SMM_FEATURE_CONTROL register, so Examination of the reported attacks shows that whether non-SMRAM code can run in SMM that the danger of hardware firmwarization can can be configured by the initial SMM code. be analyzed in two aspects: static and dynamic. This merely bought a few years of peace until The former concerns the persistent storage of 2015, when yet another SMM vulnerability was firmware and the latter concerns the runtime discovered, this time because it needed to take security of firmware in execution. external arguments. If the pointer passed in is used without checking, SMM code can be tricked As with software, one of the key advantages into writing to its own SMRAM (pointed to by of firmware is that it is updatable. However, like the pointer) in a way that facilitates the attack. software, it also needs to run in volatile memory, All in all, these SMM issues have driven and thus needs isolation from other software. Intel to create a high-level solution, the SMM- Such factors may be neglected when firmware is Transfer Monitor (STM), first available in 2015. considered to be part of hardware. Rather than remove all vulnerabilities in SMM, STM seeks to reduce opportunities for privilege escalation via SMM by reducing the privilege of Static: Update Mechanisms SMM code by wrapping it with a light-weight As long as the firmware exposes an update monitor. By enforcing necessary checks in the interface that is accessible by lower-privileged STM monitor, SMM code can be sanitized and components, including the system OS, the poten- behave as expected. However, STM has been far tial for corruption of that firmware exists. While from usable as multiple parties are involved, e.g., many such interfaces only allow firmware updates who will write best-practice/universal monitor whose integrity has been cryptographically veri- code that can verify all model-specific SMM code fied, there are various ways that verification can (there are a lot of vendors/models), and how to go awry, leading to compromise. These ways fall coordinate the OS developer, BIOS developer and in 1) Undocumented/unscrutinized interface, such hardware vendor, as STM checks would only as the VSCs of SSDs. This might be residual from proceed when all components are in agreement. factory testing or intended for easier maintenance. After the various complications of firmware 2) Improperly-protected persistent storage. One have been discussed, motherboard technologies example is the SPI flash chip on the mother- like Secure Boot (by BIOS/UEFI) and Intel Boot board where numerous types of firmware (ME, Guard (by the Intel ME) may sound less trust- BIOS/UEFI, SMM, certain SGX secrets, etc.) are worthy as a result of the many firmware vulner- stored. For example, while many motherboards abilities found in these components. only trust SMM with SPI write access [2], pre- The CPU. Last but not least, if we look further vious sections have shown that SMM itself is into the CPU, it has never been a purely hard- far from secure. 3) Defective verification. This is ware execution engine. The microcode, which mainly caused by bugs in the verification logic. can be thought of as another layer of hardware- Microcode attacks to the old CPUs [1] belong to level instructions, is used to implement more and this category.

8 IEEE Security & Privacy, to appear (accepted: May 2020) Dynamic: Memory Corruption The Closed Nature of Firmware Since firmware itself is really just software, When firmwarization already creates some it inherits vulnerabilities that can be common to concerns, what worsens the situation is that the all types of software. Memory corruption refers design and implementation of most firmware to a wide range of attacks where program defects remains proprietary and largely undocumented. may allow an attacker to alter the memory of a The security community mainly relies on reverse- program in a way not intended by the original engineering to unveil (partially) the details. programmer. It happens because certain firmware Such opaqueness hides potential problems from needs to be loaded into volatile memory for the public while real attacks do not necessar- execution, even if it is stored in an immutable ily depend on public information. It has been location. Memory safety remains an open re- well documented that security-through-obscurity search problem for regular software, let alone the does not work, and rather, can lead to seri- less formalized firmware development. The latest ous vulnerabilities going unnoticed as security Intel ME vulnerabilities were a typical example: researchers/professionals must spend additional multiple buffer overflows in the kernel of the ME effort to get basic information before they can firmware. discover and disclose vulnerabilities. Lessons-learned and the Way Forward Dynamic: Shared Address Space All the aforementioned firmware attacks show that compromise no longer needs physical access, In addition, firmware may not have physical i.e., the desired hardware property of modifi- isolation, but only logical isolation from regular cations requiring physical access is void. This software running on the same system, which may completely contradicts the common perception of be prone to flaws and vulnerabilities. This is hardware immutability. in contrast with non-Turing-complete hardware Moreover, the security of software depends on that does not share resources with software or is the underlying hardware. If the threat model of a physically isolated. computer system assumes that hardware is to be • Insufficient separation. Firmware memory trusted, then compromised hardware undermines is often visible or can be configured to all security guarantees. Therefore, firmwarized be visible to regular software for conve- hardware can cause both the hardware and the nience, performance or other reasons. For software to fail. We examine some possible ap- example, shared cache memories, memory- proaches to better securing firmwarized hardware. mapped I/O and memory reclaiming can all cause unintended access. The past exploits Can Attacks Be Mitigated by Avoiding of both SMM and ME were related to such Firmwarization? insufficient separation, e.g., the ME proces- A large number of firmware attacks target “re- sor needs to “steal” a region from the main flashing” the persistent storage and thus are static, memory due to its own limited SRAM. affecting the immutability. If firmarization did not • DMA (Direct Memory Access). This applies exist, there would be no update mechanisms, so to all high-bandwidth device firmware. To such attacks would no longer be possible. Other reduce the main CPU’s intervention as a attacks target the runtime protection of firmware performance bottleneck, the CPU’s memory and are thus dynamic. Similarly, if there were no controller allows devices and the system firmarization, such attacks would fail, as hardware software to set up memory ranges that can does not need a shared address space, nor is it be accessed by both the device processor susceptible to memory corruption, and thus this and the CPU. Then, the device processor attack vector would also be removed. can move data autonomously. Enabled by its It would then appear that an easy security controllers, the DMA opens a hole in the solution to firmwarization is to do away with already-separate spaces, i.e., exposing mem- it. However, as explained earlier, there are many ory to USB/SATA storage/network devices. non-security reasons to use firmware. Firmware

May/June 2020 9 allows the possibility of different implementa- OpenWrt. tions that trade-off efficiency and cost, a feature Least privilege. When vulnerabilities do ap- that is very important for a broad and healthy pear, reducing the damage they can cause is as computing industry. In addition, having hardware important as preventing them. Firmware’s privi- be partially field-updatable has many important leges may be managed by a lower minimal layer benefits that cannot be ignored. for fine-grained access control. Finally, it should be noted that hardware with To address the insufficient separation issue, no (updatable) firmware can still contain bugs. the least privilege approach can be taken to fur- Indeed, one of the variants of the Spectre vul- ther consider an improved firmware model that nerability cannot be patched via a firmware (i.e. abstracts away more from software, instead of microcode) update as it is embedded directly in tolerating sharing with access control. the hardware logic. Thus, being able to patch Economy of mechanism. As with regular soft- the hardware when a vulnerability is discovered ware, complexity is a major contributor to vulner- is also a benefit of firmware, from a security abilities. Traditionally, hardware being difficult to perspective, as opposed to leaving doors open for patch, has had economy of mechanism “baked attackers with completely immutable hardware. in” by necessity. With increasing use of firmware, For these reasons, it would seem that the benefits this traditional bias towards simplicity and con- of firmwarization may outweigh its supposed servative design has been eroded. We advocate threats to security, and thus we should instead a return to those original design principles due search for methods to make firmwarized hardware to the highly privileged and trusted nature of as secure as pure hardware implementations. hardware. Related work in academia. Fortunately, some Then, should firmware be treated the same way of the discussed issues have already attracted as software? attention in the research community and led to As firmwarization is inevitable, it is important progress in firmware security research. Zhang et to admit that the vast quantities of code fulfilling al. proposes IOCheck[11] to verify the firmware hardware functions deserve at least the same (or integrity of various peripherals by directly reading more) degree of attention as regular software. peripheral memory. One major concern is that Yet, these highly trusted, low-level software com- IOCheck relies on SMM as the trust anchor ponents are often opaque in their functionality. to perform checks. If SMM is no more secure Their proprietary nature prevents open auditing than other firmware, then tools depending on it and validation of their security. Their low-level cannot be relied upon. Also, the heterogeneity privileges often encourage complex and unrelated of peripherals can make the firmware retrieval functionality to be packed into their implementa- very difficult, not to mention maintaining all the tion. correct checksum/signatures. At least, IOCheck Experience has shown time and again that the sheds some light on the assurance of overall notion of hardware-assisted security approaches firmware integrity, not specific to a device type. may end up relying on firmwarized hardware, To address a subset of the BadUSB problem, in one way or another. Therefore, a change of USBCheckIn [15] uses human user’s physical mindset is necessary for hardware vendors and interaction with HID devices (e.g., keyboards the research community: we must treat firmware and mice) to detect misbehavior. This proposal the same way as software. points to a new direction of firmware integrity: Firmware security engineering. Security design checking the behavior of a device against a set of principles widely accepted for software, such as specifications before trusting it. Saltzer and Schroeder’s design principles [10] can Through this article, we hope to waken the also be applied to firmware, in particular: community’s awareness of the phenomenon that Openness. Public scrutiny helps minimize an increasingly greater part of modern hardware straightforward issues caused by opaqueness. is implemented in “software”. In light of this, the Some open frameworks can serve as references phrase “software is eating the world” seems to for secure designs of firmware, e.g., coreboot and apply to more than just startup companies. We

10 IEEE Security & Privacy, to appear (accepted: May 2020) worry that this trend has implications for the se- Wroclaw, Poland, pp. 219-238, 2014. (Conference pro- curity of our future computer systems, prompting ceedings) us to encourage the reader to consider: Is the next 12. Tom Li, NVIDIA Video BIOS Hack, 2014 [Online]. Avail- hardware-assisted security feature any better than able: https://notabug.org/niconiconi/nvresolution (URL) a software-assisted security mechanism? 13. J. Heasman, “Implementing and detecting a PCI rootkit,” Black Hat 2007. Available: https://www.blackhat.com/ REFERENCES presentations/bh-dc-07/Heasman/Paper/bh-dc-07- 1. P. Koppe, B. Kollenda, M. Fyrbiak, C. Kison, R. Gawlik, Heasman-WP.pdf (Tech. Rep.) C. Paar and T. Holz, “Reverse Engineering x86 Proces- 14. K. Nohl, S. Krißler and J. Lell, “BadUSB – On Acces- sor Microcode,” In USENIX Security’17, Vancouver, BC, sories that Turn Evil,” PacSec’14, Tokyo, Japan, 2014, Canada, 1163–1180, 2017. (Conference proceedings) Available: https://srlabs.de/wp-content/uploads/2014/11/ 2. C. Kallenberg, J. Butterworth, X. Kovah and S. Cornwell, SRLabs-BadUSB-Pacsec-v2.pdf (Conference proceed- “Defeating signed BIOS enforcement,” The MITRE ings) Corporation, 2014. Available: https://www.mitre.org/sites/ 15. F. Griscioli, M. Pizzonia and M. Sacchetti, “US- default/ﬁles/publications/defeating-signed-bios- BCheckIn: Preventing BadUSB attacks by forcing enforcement.pdf (Tech. Rep.) human-device interaction,” PST’16, Auckland, New 3. J. Zaddach, A. Kurmus, D. Balzarotti, E-O. Blass, A. Zealand, 2016, pp. 493-496. (Conference proceedings) Francillon, T. Goodspeed, M. Gupta and I. Koltsidas , “Implementation and Implications of a Stealth Hard-Drive Backdoor,” In ACSAC’13, New Orleans, LA, USA, 2013. (Conference proceedings) 4. A. Opler, “Fourth generation software,” Datamation., 13(1), 22-24, Jan. 1967. (Journal) 5. K. Chen, “Reversing and exploiting an Apple ﬁrmware update,” Black Hat 2009. Available: https:// www.blackhat.com/presentations/bh-usa-09/CHEN/ BHUSA09-Chen-RevAppleFirm-PAPER.pdf (Tech. Rep.) 6. C. Meijer and B. van Gastel, “Self-encrypting deception: weaknesses in the encryption of solid state drives (SSDs),” Radboud University and Open University of the Netherlands, 2018. Available: https://www.ru.nl/publish/pages/909282/draft-paper.pdf (Tech. Rep.) 7. A. Baumann, “Hardware is the new software,” HotOS’17, Whistler, BC, Canada, pp. 132-137, ACM, 2017. (Confer- ence proceedings) 8. R. de Clercq and I. Verbauwhede, “A survey of Hardware-based Control Flow Integrity (CFI),” KU Leu- ven, 2017. Available: https://arxiv.org/ftp/arxiv/papers/ 1706/1706.07257.pdf (Preprint) 9. Anonymous, “Opteron exposed: Reverse engineering AMD K8 microcode updates,” 2004 [Online]. Available: https://securiteam.com/securityreviews/5FP0M1PDFO/ (URL) 10. J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,” Proceedings of the IEEE, 63(9), 1278-1308, 1975. (Conference proceedings) 11. F. Zhang, H. Wang, K. Leach and A. Stavrou, “A frame- work to secure peripherals at runtime,” ESORICS’14,

May/June 2020 11