Subverting Trusted Platform Module While You Are Sleeping (PDF)

Open access to the Proceedings of the 27th USENIX Security Symposium is sponsored by USENIX. A Bad Dream: Subverting Trusted Platform Module While You Are Sleeping Seunghun Han, Wook Shin, Jun-Hyeok Park, and HyoungChun Kim, National Security Research Institute https://www.usenix.org/conference/usenixsecurity18/presentation/han This paper is included in the Proceedings of the 27th USENIX Security Symposium. August 15–17, 2018 • Baltimore, MD, USA ISBN 978-1-939133-04-5  A Bad Dream: Subverting Trusted Platform Module While You Are Sleeping Seunghun Han Wook Shin Jun-Hyeok Park HyoungChun Kim National Security Research Institute {hanseunghun, wshin, parkparkqw, khche}@nsr.re.kr Abstract This paper reports two sorts of Trusted Platform Mod- ule (TPM) attacks regarding power management. The at- tacks allow an adversary to reset and forge platform con- figuration registers which are designed to securely hold measurements of software that are used for bootstrapping a computer. One attack is exploiting a design flaw in the TPM 2.0 specification for the static root of trust for mea- surement (SRTM). The other attack is exploiting an im- plementation flaw in tboot, the most popular measured launched environment used with Intel’s Trusted Execu- tion Technology. Considering TPM-based platform in- tegrity protection is widely used, the attacks may affect a large number of devices. We demonstrate the attacks with commodity hardware. The SRTM attack is sig- nificant because its countermeasure requires hardware- specific firmware patches that could take a long time to be applied. 1 Introduction The Trusted Platform Module (TPM) was designed to provide hardware-based security functions. A TPM chip is a tamper-resistant device equipped with a random number generator, non-volatile storage, encryption func- tions, and status registers, which can be utilized for appli- cations such as ensuring platform integrity and securely storing keys. The Trusted Computing Group (TCG) is an industry consortium whose goal is to specify and stan- dardize the TPM technology, which includes security- related functions, APIs, and protocols. The initial ver- sion of the TPM main specification (TPM 1.2) [31] was published in 2003. The revised version, the TPM library specification 2.0 (TPM 2.0) [37] was initially published in 2013. The TPM technology provides a trustworthy founda- tion for security-relevant applications and services. TPM is a major component of the integrity measurement chain that is a collection of system components such as the bootloader, kernel, and other components. The chain can either start statically from Basic Input and Output System (BIOS)/Unified Extensible Firmware Interface (UEFI) code modules when the system is booted or dynamically from a specialized instruction set during runtime. Regardless of how the chain starts, the measure- ments are “extended” to platform configuration registers (PCRs) inside the TPM. When a value is extended to a PCR, the value is hashed together with the previously stored value in the PCR and then the PCR is updated with the hashed result. A small bit change to a PCR value will affect all the following extended values. The extended values in PCRs can be compared to expected values lo- cally or submitted to a remote attestor. Namely, the in- tegrity measurement chain must be started from a trust- worthy entity, also known as the root of trust for mea- surement (RTM). The TPM has been widely deployed in commodity de- vices to provide a strong foundation for building trusted platforms, especially in devices used in enterprise and government systems. The US Department of Defense also considers the TPM to be a key element for dealing with security challenges in device identification and au- thentication, encryption, and similar tasks. The TPM chip is designed to cooperate with other parts of the system, e.g., the firmware and the operating system. Mechanisms for cooperation are often compli- cated and fail to be clearly specified. This may result in critical security vulnerability. Power management is one of the features which in- creases complexity of the cooperation. The goal of power management is to save power by putting the sys- tem into a low-power state or even cutting off the power when the system is idle. How the power management works is quite complicated because each peripheral de- vice can have its own power state independently from the system-wide power state. A recent Linux kernel supports the Advanced Config- USENIX Association 27th USENIX Security Symposium 1229  uration and Power Interface (ACPI), which is an open industry specification that enables operating system- centric intelligent and dynamic management coordina- tion with power management-aware devices such as CPUs, networks, storage, and graphics processing units. TPM is a peripheral that supports ACPI. The informa- tion stored in the TPM chip such as keys and state val- ues are very important for maintaining the security of the whole system, TPM has to actively and safely save and restore the state as the power state changes. Unfortunately, the TPM does not safely maintain the state when the power state changes. We found vulnera- bilities in both types of RTM that allow an adversary to reset and forge PCRs when the system wakes up. There- fore, the system may look normal even after it has been modified. Considering that TPM has been widely de- ployed, the impact of our finding is critical, especially when it comes to static measurement. The vulnerabil- ity of a static RTM (SRTM) is due to a flawed specifi- cation, which means that many products that implement the specification can be affected and patches would not be applicable to all of the products immediately. The vulnerability of the dynamic RTM (DRTM) is due to a bug in the open source project, tboot, which is the most popular measured launch environment (MLE) for Intel’s Trusted eXecution Technology (TXT). Patching the bug is relatively simple, and our patch1 can be found on the tboot project [9]. We also have obtained Common Vulnerabilities and Exposures (CVE) identifiers: CVE- 2018-6622 for the SRTM and CVE-2017-16837 for the DRTM attack, respectively. This paper makes the following contributions: • We present vulnerabilities that allow an adversary to reset the PCRs of a TPM. The PCRs are reset- table whether the RTM processes start statically or dynamically. • We craft attacks exploiting these vulnerabilities. The attacks extract normal measurements from the event logs recorded during the boot process, and then they use the measurements to perform a replay attack. • We also address countermeasures for these vul- nerabilities. To remedy the SRTM vulnerability that we found, hardware vendors must patch their BIOS/UEFI firmware. We have contacted them and are waiting for releases of the patches. We also pro- duced a patch by ourselves for the DRTM vulner- ability that we found. We have obtained the CVE IDs of both vulnerabilities. In the following sections, we review TPM and ACPI technologies. Then, we introduce their vulnerabilities 1The commit hash is 521c58e51eb5be105a29983742850e72c44ed80e BIOS/UEFI firmware S-CRTM BIOS/UEFI Code TPM Bootloader Kernel User Applications : Extend a hash of next code to TPM : Execute next code Static Root of Trust for Measurement D-CRTM (DCE) TPM tboot (DLME) Bootloader User Applications Dynamic Root of Trust for Measurement (Intel Trusted Execution Technology) Untrusted Code Power On/ Restart DL Event Kernel Figure 1: Examples of static and dynamic RTM (SRTM and DRTM, respectively) processes and exploits against them. The exploits are demonstrated in a variety of commercial off-the-shelf devices. The re- sults of the attacks are presented in this paper. We also suggest different ways of mitigating the vulnerabilities that we found. 2 Background 2.1 TPM Technology A trusted computing base (TCB) [37] is a collection of software and hardware on a host platform that enforces a security policy. The TPM helps to ensure that the TCB is properly instantiated and trustworthy. A measured boot is a method of booting in which each component in the boot sequence measures the next component before pass- ing control to it. In this way, a trust chain is created. The TPM provides a means of measurement and a means of accumulating these measurements. PCRs are the mem- ory areas where the measurements can be stored. When a measurement is “extended” to a PCR, the measurement is hashed together with the current value of the PCR, and the hashed result replaces the current value. As long as the values are updated in this way, it is easy to find an alteration in the middle of the chain. A particular value of a PCR can be reproduced only when the same val- ues are extended in the same order. The trustworthiness of the platform can be determined by investigating the values stored in PCRs. It is also possible to request the PCR values remotely. Remote attestation is a challenge- response protocol that sends PCR values in the form of a digitally signed quote to a remote attestor. The TPM also functions as a secure storage by provid- 1230 27th USENIX Security Symposium USENIX Association  PCR Index PCR Usage 0 S-CRTM, BIOS, host platform extensions, and embedded option ROMs 1 Host platform configuration 2 BIOS: Option ROM code UEFI: UEFI driver and application code 3 BIOS: Option ROM configuration and data UEFI: UEFI driver, application configuration, and data 4 BIOS: Initial Program Loader (IPL, e.g., bootloader) code and boot attempts UEFI: UEFI boot manager code (e.g., bootloader) and boot attempts 5 BIOS: IPL code configuration and data UEFI: Boot manager code configuration, data, and GPT partition table 6 BIOS: State transitions and wake events UEFI: Host platform manufacturer specific 7 BIOS: Host platform manufacturer specific UEFI: Secure boot policy 8-15 Defined for use by the OS with SRTM 16 Debug 17-22 Defined for use by the DRTM and OS with DRTM 23 Application support Table 1: Summary of PCR usage (TPM 1.2 and 2.0) ing “sealing” and “binding” operations that limit access to the storage based on a specific platform state. For ex- ample, a TPM’s “sealed” data can be decrypted by the TPM only when the PCR values match specified values. “Unbinding” data is done by a TPM using the private key part of the public key used to encrypt the data. Binding can be done by anyone using the public key of a TPM, but unbinding is done by the TPM only because the pri- vate key part is securely stored inside TPM and is even locked to specific PCR values. A chain of trust is an ordered set of elements in which one element is trusted by its predecessor. The trustwor- thiness of the whole chain depends on the first element. An RTM is the trust anchor of a measurement chain. A TPM is designed to report the platform state securely, but it cannot initiate the measurements by itself. Initiating the measurement is done by another software component that can be trusted called the core RTM (CRTM). Fig- ure 1 shows two different types of RTM: SRTM [32, 39] and DRTM [33]. In addition, Table 1 shows the PCR usage for SRTM and DRTM. SRTM is the trust anchor that is initialized by static CRTM (S-CRTM) when the host platform starts at power-on or restarts. Often, SRTM is an immutable software program that is stored in ROM or a protected hardware component. In contrast, DRTM launches a OS ACPI (BIOS/UEFI) TPM (2) Request to enter sleep (4) Wake up (1) Request to save state (5) Request to restore state Sleep (S3, S4) (3) Sleep (6) Resume OS Figure 2: ACPI sleep process with TPM measured environment at runtime without platform re- set. When the dynamic chain of trust starts with a dy- namic launch event (DL Event), the DRTM configura- tion environment (DCE) preamble performs the initial configuration and prepares the DRTM process [33, 43]. As the DRTM process starts, the special code module (the DCE), is executed as a dynamic CRTM (D-CRTM), validates whether the platform is trustworthy, and trans- fers the control to the initial part of the operating system, called the dynamically launched measured environment (DLME). A chain of trust can be expanded to user-level appli- cations beyond the operating system kernel. Integrity Measurement Architecture (IMA) [26] measures appli- cations before executing them. IMA is included in the kernel, and therefore its authenticity can be guaranteed by the trust chain. 2.2 ACPI Sleeping States ACPI [42] is an open standard for architecture- independent power management. It was released in 1996 after being co-developed by Intel, Hewlett-Packard (HP), and other companies. The ACPI specification defines power states and the hardware register sets that represent the power states. There are four global power states, defined as working (G0 or S0), sleeping (G1), soft-off (G2), and mechanical- off (G3). The sleeping state is divided into four sleeping states: • S1: Power on Suspend. The CPU stops execut- ing instructions, but all devices including CPU and RAM are still powered. • S2: The same as S1 except the CPU is powered off. USENIX Association 27th USENIX Security Symposium 1231  • S3: Sleep (Suspend to RAM). All devices are powered-off except for RAM. • S4: Hibernation (Suspend to Disk). The platform context in the main memory is saved to disk. All devices are powered off. Like other devices, a TPM chip is powered off in states S3 or S4. The TCG specifications [32, 39] define how the state is maintained while the power state changes. They also define the roles of the operating system and BIOS/UEFI firmware. The steps defined for saving and restoring the TPM state are summarized in Figure 2. Be- fore sleep, the operating system requests the TPM chip to save the state, and then makes a transition to sleeping states by sending a request to the ACPI in the BIOS/UEFI firmware. All hardware devices are either powered off (in S4) or only the main memory remains powered (in S3). When the platform exits from the sleeping states, the BIOS/UEFI firmware requests the TPM to restore the state and then it starts the operating system. The TCG specification describes the role of power management over the operating system and the BIOS/UEFI firmware. Power management will be ef- ficient and work as long as the operating system and firmware cooperate well. For the S3 sleep function to work properly, each part must function perfectly with- out error; however, this state may collapse when one part malfunctions, which is hard to correct using the other parts. Moreover, the power management of a TPM chip needs to be carefully considered when it is partly han- dled by an operating system that could be compromised by rootkits [29]. In Section 4, we demonstrate how in- complete power management control breaks the chain of trust. 3 Assumptions and Threat Model 3.1 Assumptions First, we assume that our system measures the firmware and bootloader using TCG’s SRTM [32, 39]. Many com- modity laptops, PCs, and servers come with TPM sup- port. When their TPM support option is enabled in the BIOS/UEFI menu, the BIOS/UEFI firmware starts the “trusted boot” [25] process, which means that it mea- sures the firmware itself and the bootloader and stores the measurements in the TPM chip. Second, we assume that our system employs TCG’s DRTM architecture [43]. When a DRTM chain starts at runtime, the DRTM itself, kernel file, and initial RAM disk (initrd) file are measured, and the measurements are kept in the TPM. Both Intel and AMD have their ex- tended instructions for supporting DRTM, called TXT and Secure Virtual Machine, respectively. For our ex- periments, we use Trusted Boot (tboot) [11], which is an open source implementation of the Intel TXT [12]. We also assume that the stored measurements in TPM are verified by a remote attester. These measurements should be unforgeable by an attacker; therefore, any modification in the firmware, bootloader, or kernel will be sent to and identified by an administrative party. 3.2 Threat Model We consider an attacker who has already acquired the Ring-0 privilege with which the attack can have the ad- ministrative access to the software stack of a machine including the firmware, bootloader, kernel, and applica- tions. The attacker might use social engineering to ac- quire this control or could exploit zero-day vulnerabil- ities in the kernel or system applications. The attacker may be able to safely upgrade the UEFI/BIOS firmware to a new and manufacture-signed one. However, we as- sume that he or she cannot flash the firmware with arbi- trary code. We also assume that the attacker cannot roll- back to an old version of the firmware, where the attacker can exploit a known vulnerability. The attacker’s primary interest is to hide the breach and retain the acquired privileges for further attacks. TPM and SRTM/DRTM should measure the system and securely leave proof in the PCRs if the bootstrapping software or kernel has been modified. This proof also can be delivered to and verified by a remote administra- tor. The attacker may try to compromise the bootloader and kernel by modifying files in the EFI partition and under /boot/. This is feasible because we assume the at- tacker has privileged accesses to every part of the sys- tem software. Moreover, it is easy to obtain, modify, and rebuild the bootloader, kernel, and kernel drivers. The GRand Unified Bootloader (GRUB) and TPM driver that we used in our experiments are accessible via a GitHub repository [5, 19]. Namely, the attacker can boot the sys- tem with a modified bootloader or with another boot op- tion if the system has multiple boot options. The TPM and SRTM/DRTM are supposed to securely record and report the fact that the system has not booted with an expected bootloader and configuration. However, they would fail to do that. We do not consider a denial-of-service attack in this paper. If the attacker has system privileges, he or she can easily turn the system off. We also do not consider hardware attacks that require a physical access to the sys- tem circuits. Vulnerabilities of the System Management Mode (SMM) [13] may allow the attacker to remotely and pragmatically alter firmware binary or change the BIOS/UEFI options [6], but we do not consider such vul- 1232 27th USENIX Security Symposium USENIX Association  Specifications (TCG, UEFI, etc.) Implementations NTC, Infenion, STMicroelectronics, Atmel, Broadcom, etc. ASUS, GIGABYTE, DELL, HP, Lenovo, IBM, Samsung, LG, etc. TPM Vendors Mainboard/PC Vendors Figure 3: TPM technology entities nerabilities. Rather, we show that the TPM and SRTM/- DRTM can fail without the need to exploit them. 4 Vulnerability Analysis 4.1 Finding the Security Vulnerabilities Bootstrapping a system utilizing TPM and SRTM/- DRTM technologies involves many entities, and Figure 3 shows their relationships. Security vulnerabilities can be found when formally analyzing the design and specifica- tion of a system, however, it is challenging to formally specify them anyway. Instead, we basically reviewed the specification documents manually and tested real sys- tems. The steps we took to find the vulnerabilities are as follows: 1. While reviewing the TCG specification, we found a change in the TCG specification from TPM 2.0 to TPM 1.2 regarding power management. The differ- ence was regarding restarting TPM when the system resumes [37]. 2. Using a real system with support for TPM and SRTM, we tested how a TPM state can be saved and restored as the power state cycles. We found an abnormal behavior when the TPM state is re- set. We speculated that the failure was due to the firmware implementations not meeting the specifi- cation or ambiguity in the specification [37]. Note that another flaw caused by not meeting the TCG specification has been reported already [3]. 3. Based on speculation, we tested other implemen- tation instances of the specification. We could have investigated the firmware source code, but we needed to experiment with a number of products be- cause the firmware of these products is not open. Eventually, the same vulnerability was confirmed in several systems. (1) Review a specification - Unverified changes or inconsistency in document (2) Do a case study - Test with an implementation instance, or investigate the code (3) Analyze the problem Speculations Problem confirmed (b) Possibly exists in other implementations? (proceed with another implementation instance) (a) Possibly exists in similar specifications? (proceed with another specification) (b) (a) Figure 4: General process of the vulnerability analysis in TPM 4. We investigated the DRTM specifications. At this time, we thought we could apply what we learned to the DRTM, which is similar to the SRTM. In the DRTM, the DCE and DLME are verified, ini- tialized, and launched by hardware support, which means the process is performed by immutable par- ties. 5. We investigated the open source implementation of DRTM, tboot [11], which is based on Intel TXT. The vulnerability of an authenticated code module (ACM), which is the DCE of Intel TXT, as reported by Wojtczuk and Rutkowska [44, 45] demonstrates that the authenticity and integrity of code are not guaranteed to be flawless. Unlike previous studies, we focus on tboot, which is the DLME, and even- tually found mutable function pointers that we were able to exploit. We summarize this process in Figure 4. 4.2 SRTM Vulnerability: CVE-2018-6622 4.2.1 Problem: The Grey Area SRTM starts up the chain of trust by measuring each component of the boot sequence including the BIOS/UEFI firmware, bootloader, and kernel. The mea- surements are extended to the PCRs, from PCR #0 to PCR #15. An alteration of a booting component would leave different values in the PCRs. The alteration can easily be identified when the values are then compared to the correct ones. It is known that it is difficult for malicious software to become involved in the booting sequence and forge PCR values to hide its involvement. To forge these values, the USENIX Association 27th USENIX Security Symposium 1233  malicious software needs to reset the TPM and extend the exact same series of measurements. This is infeasible because the TPM reset requires a host platform to restart. However, we recently found that PCRs can be initial- ized when the host platform sleeps. When the platform enters into the S3 or S4 sleeping states, the power to the devices is cut off. TCG specifies how TPM can sup- port power management [32, 37]: TPM is supposed to save its state to the non-volatile random access mem- ory (NVRAM) and restore the state back later. How- ever, the specification does not specify sufficiently how it should be handled when there is no saved state to be restored [39]. As a result, some platforms allow software to reset the PCRs and extend measurements arbitrarily. A TPM typically has two power states, the working state (D0) and the low-power state (D3). The TPM has a command for saving its state before putting itself into the D3 state and a command for restoring the saved state when getting out of the D3 state. According to the TPM 1.2 specification [32], the operating system may enter into the S3 sleeping state after notifying the TPM that the system state is going to change by sending it the TPM SaveState command. On exiting from the S3 sleeping state, the S-CRTM determines whether the TPM should restore the saved state or be re-initialized. When S-CRTM issues TPM Startup(STATE), the TPM restores the previous state. When TPM Startup(CLEAR) is is- sued, the TPM restarts from a cleared state. An unexpected case that could reset the TPM can oc- cur if there is no saved state to restore. How to tackle this problem is specified differently in the TPM 1.2 and 2.0 specifications. In version 1.2 [32], TPM enters fail- ure mode and is not available until the system resets. In version 2.0, TPM2 Shutdown() and TPM2 Startup() correspond to TPM SaveState() and TPM Startup(), re- spectively. Version 2.0 [39] tells TPM to return TPM RC VALUE when TPM2 Startup(STATE) even if it does not have a saved state to restore. It also speci- fies that the SRTM should perform a host platform reset and send the TPM2 Startup(CLEAR) command before handing over the control to the operating system. Restarting the SRTM and clearing the TPM state is not sufficient to assure the integrity of the platform. It is simply the same as resetting the TPM. An adversary can hence still extend an arbitrary value to the PCRs. This must be forbidden. Otherwise, there should be a way to warn that the TPM state has been reset abnormally. Although another specification document [37] states that the CRTM is expected to take corrective action to prohibit an adversary from forging the PCR values. However, the specification does not either mandate it or explain how to do this in detail. The incompleteness of this specification may lead to inappropriate implemen- tations and eventually destroy the chain of trust. How Compromised Software Stack Normal State (TPM shows normal PCRs) Leaves normal hashes in event logs Compromised State (TPM shows abnormal PCRs) BIOS/UEFI Sleep Sleep without saving the TPM state Compromised Software Stack Wake up Faked State (Still compromised but TPM shows the normal PCRs) Extract and calculate the normal hashes Reset the TPM and replay the normal hashes Store the normal hashes in RAM Reboot Hash values Figure 5: Exploit scenario for the SRTM vulnerability an adversary forges the measurements is demonstrated in Section 4.2.2. 4.2.2 Exploit Scenario The aim of an exploit is to conceal the fact that the sys- tem has been compromised. By assumption, our attacker has already taken control of the system software includ- ing the bootloader and the kernel. Figure 5 depicts the main points of the exploit scenario. The attacker ob- tains good hash values from the BIOS/UEFI event logs, which are recorded during a normal boot process. As- sorted hash values are stored in RAM temporarily, and are finally handed over to the kernel. The attacker can forge PCR values using the obtained hashes after sleep. As a result, the TPM shows that the system is booted and running with genuine software, which is not at all true. The technical details of the exploit are explained in Sec- tion 4.2.3. 4.2.3 Implementation in Detail We explain how to reset the TPM state and counterfeit the PCR values. Figure 6 shows the detailed process of exploiting SRTM vulnerability. First, before resetting and replaying the TPM, we need 1234 27th USENIX Security Symposium USENIX Association  !"#$%&'"()*+,-,...' !"#$/&'0%10"-23...' ...' !"#"$%"&'($")' *+,-++++'.'+,/++++0' 1"11)23456' 7+,-++++' 6"$8"9':)$)1";"$' <9""2'=>;[email protected];'B:CD<)%"<;);"*0')8&'' B:CED<?A;&@=8*0' F0'G,;$)H;';?"'[email protected]$1)9'?)#?"#' ''''[email protected]';?"'$"#"$%"&')$")' E0'J)9HA9);"'?)#?"#'@I' '''';?"'[email protected]$1)9'[email protected]@;[email protected])&"$')8&'' '''';?"'L"$8"9'*:J!'M5')8&'' '''':J!'M/0' NOP<QRGSO'I)>9#';@'$"#;@$"';?"'B:C' #;);"')8&'$"#A1"#';?"'L"$8"9' F0'!"#";':J!#'=>;?' ''''B:CD<;)$;A2*JTG(!0'@$'' ''''B:CED<;)$;A2*JTG(!0' E0'!"29)U';?"'[email protected]$1)9'?)#?"#' !"##$% &'(#%)$% NOP<QRGSO' *+,-'"%!.'.#% *B:C'#[email protected]=#'[email protected]$1)9' :J!#0' F0'J?)8V"';?"'[email protected]@;[email protected])&"$'' '''')8&';?"'L"$8"9' E0'!"[email protected]@;';?"'#U#;"1' [email protected]$1)9':J!#' !"#$%&'"()*+,-,...' !"#$/&'0%10"-23...' ...' G%"8;'[email protected]#' [email protected][email protected]>#"&' [email protected]@;[email protected])&"$' ,"*)23/2...' !"#$%' ...' ...' !"#$%&'#...' (")*%+ ...' ...' ,,-,.&./...' (")*&+ ...' ...' %%%%%%%%...' !"#$)4' [email protected][email protected]>#"&' 6"$8"9' [email protected]$1)9'X)#?'Y)9A"#' !"#$%&'"()*+,-,...' !"#$/&'0%10"-23...' ...' (")*%&'%!"0-"1#...' '(")*&&'232%3.-'...'' ([email protected]$1)9':J!#' *:J!'M5')8&':J!'M/')$"'&>II"$"8;0' ,"*)23/2...' !"#$%' ...' ...' 1'$310%2...' (")*%+ ...' ...' 13#2'-2&...' (")*&+ ...' ...' %%%%%%%%...' !"#$)4' NOP<QRGSO' !/%!"##$012%!.'.#% NOP<QRGSO' [email protected][email protected]>#"&' 6"$8"9' <)%"'[email protected]$1)9'?)#?"#';@'' ;?"'$"#"$%"&')$")' [email protected]$1)9':J!#' ,"*)23/2...' !"#$%' ...' ...' !"#$%&'#...' (")*%+ ...' ...' ,,-,.&./...' (")*&+ ...' ...' %%%%%%%%...' !"#$)4' 3+-$,+-04#5%!.'.#% *B:C'#[email protected]=#')[email protected]$1)9' :J!#0' 6'(#5%!.'.#% *<;>99'[email protected][email protected]>#"&' KA;'B:C'#[email protected]=#';?"'[email protected]$1)9' :J!#0' Figure 6: Detailed process of exploiting the SRTM vul- nerability the normal digest values. The normal digests can be ex- tracted from the TCG event logs. When a value is ex- tended to a PCR, the firmware makes an entry in the TCG event logs for later verification. According to TCG ACPI specification [38], the starting address of the pre- boot event logs is written in the Local Area Start Address field of the Hardware Interface Description Table in the ACPI table. This field is located at offset 42 in TPM 1.2, whereas it is optionally located at offset 68 in TPM 2.0. Bootloader BIOS support UEFI support TPM 1.2 TPM 2.0 GRUB for CoreOS [5] ✓ ✓ ✓ ✓ Trusted- GRUB1 [40] ✓ ✓ Trusted- GRUB2 [41] ✓ ✓ GRUB- IMA [24] ✓ ✓ Table 2: List of bootloaders with BIOS/UEFI support and TPM version When the field is not there, there is another option for obtaining the logs. The BIOS/UEFI firmware saves the event logs separately as well for its own use. These logs are accessible until the control is given to the kernel in UEFI mode because they are removed when ExitBoot- Service() is called [36]. To obtain and reuse the normal digests in the logs, we crafted exploits modifying an existing bootloader and the kernel. The bootloader calls the GetEventLog() UEFI in- terface and collects all event logs. The logs are passed to the kernel through a reserved memory region. The logs are saved in a 64K memory block starting from 0x80000, which is below the 1MB address space. This area should be excluded from the kernel range by setting the kernel’s command line parameter “memmap = 64K $ 0x80000” so that the data written in that region can be kept after booting. Our exploit in the kernel resets TPM by making the system enters the S3 sleeping state, and finally ex- tends the measurements, one after another, in the normal order as presented in the logs. We take the GRUB implementation from the open source Container Linux [4] to implement our exploit. To our knowledge, it is the only existing bootloader im- plementation that supports UEFI and both versions of the TPM. Table 2 summarizes the bootloaders that have TPM support. Our customized bootloader functions as the SRTM and extracts the event logs for both TPM 1.2 and 2.0. Figure 7 shows an example of the event logs extracted from an Intel mini PC (NUC5i5MYHE). The normal measurements can be obtained after pars- ing the event logs. A log entry of the event logs is composed of a PCR index, an event type, a digest, an event size, and event data. The PCR index is the PCR to which a digest is extended. The event type can be either a CRTM version, UEFI firmware variable, initial program loader (IPL), or IPL data. Table 3 summarizes the types needed to parse the event logs. The digest is the hashed result of binary or text values depending on the event type, whereas the event data stores raw data. The event size is the size of the raw data. The parsed digest values, except for the nor- USENIX Association 27th USENIX Security Symposium 1235  Dump Address 0 xFFFFB8FFC1E40000 (Physical Address 0x80000) TCG Event_version = 1 PCR 0, Event Type 0x8 , Size 16, Digest C42FEDAD268200CB1D15F97841C344E79DAE3320 PCR 7, Event Type 0x80000001 , Size 52, Digest 2 F20112A3F55398B208E0C42681389B4CB5B1823 PCR 7, Event Type 0x80000001 , Size 36, Digest 9 B1387306EBB7FF8E795E7BE77563666BBF4516E PCR 7, Event Type 0x80000001 , Size 38, Digest 9 AFA86C507419B8570C62167CB9486D9FC809758 PCR 7, Event Type 0x80000001 , Size 36, Digest 5 BF8FAA078D40FFBD03317C93398B01229A0E1E0 PCR 7, Event Type 0x80000001 , Size 38, Digest 734424 C9FE8FC71716C42096F4B74C88733B175E PCR 0-7, Event Type 0x4 , Size 4, Digest 9069 CA78E7450A285173431B3E52C5C25299E473 PCR 5, Event Type 0x80000006 , Size 484, Digest 5 C64EDAEA674F708F24B152A79AF26D45990BF65 PCR 4, Event Type 0x80000003 , Size 186, Digest 41 C06CD2A38EB0B6208A93D0227E5C49668AA550 PCR 8, Event Type 0xD , Size 75, Digest 3 EDC5474CC2D9BDCCAB031E75C6C7C3DF06DF729 ... omitted ... Figure 7: TPM event logs of Intel NUC5i5MYHE extracted by the custom bootloader /* *************************************** */ /* Skip tpm_savestate and tpm2_shutdown */ /* in drivers /char/tpm/tpm -interface.c */ /* *************************************** */ int tpm_pm_suspend (struct device *dev) { ... omitted ... + printk(KERN_INFO "tpm: tpm_savestate () " + "and tpm2_shutdown () are skipped \n"); + return 0; + if (chip ->flags & TPM_CHIP_FLAG_ALWAYS_POWERED ) return 0; if (chip ->flags & TPM_CHIP_FLAG_TPM2 ) { tpm2_shutdown (chip , TPM2_SU_STATE ); return 0; ... omitted ... Figure 8: Patch code summary of custom kernel for TPM reset mal bootloader and kernel (PCR #4 and PCR #9), are the ones to be replayed. The log entry for the bootloader hash can be identified by event type EV EFI BOOT SERVICES APPLICATION (0x80000003) and the one for the kernel (including the kernel file and the initial RAM disk file) hash is identified by event type EV IPL (0x0D). Note that the digest originates from our customized bootloader and kernel, not from the original ones. The bootloader and kernel hash values can be obtained from the original bootloader and kernel instead. The bootloader hash value has to follow the Windows Authenticode Portable Executable Signature Format [23, 35]; however, the kernel hash value can be calculated using the sha1sum tool. To reset the TPM, two tasks must be performed. One is to modify the kernel so that it skips to sav- ing the TPM state and calling TPM Startup(CLEAR) or TPM2 Startup(CLEAR) after waking up. The code listed in Figure 8 shows how simple this modifica- tion is. We add return code at the start of function tpm pm suspend() and call function tpm startup() in the TPM driver using our test kernel module (see include/lin- ux/tpm.h [19]). The other task is to wait until the sys- tem sleeps or make the system sleep by giving a sus- pend command like the ones that systemd or the pm- utils package provides. After resetting the TPM, the nor- mal measurements can be re-extended. We call function tpm pcr extend() in the TPM driver to replay the hashes. 4.3 DRTM Vulnerability: CVE-2017- 16837 4.3.1 Problem: Lost Pointer DRTM builds up the dynamic chain of trust at runtime, and it uses the set of PCRs from PCR #17 to PCR #22. These dynamic PCRs [32, 39] need to be initialized dur- ing runtime, but the initialization is restricted to locality 4 [34], which means their access is controlled by trusted hardware and not accessible to software. However, in addition to the hardware buttons, there is another chance to reset the PCRs. The dynamic PCRs are initialized when the host platform escapes from the S3 and S4 sleep- ing states. The DRTM specification [33] explains how DRTM can be reinitialized after the sleeping states. 4.3.2 Exploit Scenario To undermine a DRTM, some of the extended measure- ments sent to dynamic PCRs should be forgeable. This is not easy because the DCE, being executed prior to the DLME [33], launches the DLME after extending the measurement of the DLME, as shown in Section 2, how- ever, after the DLME has started, security is a matter of the trustworthiness of the DLME. In other words, it is still possible to break the dynamic trust chain as long as the DLME implementation has own vulnerability. As shown in Figure 9, the DRTM exploit is mostly similar to the SRTM one. The attacker obtains the good 1236 27th USENIX Security Symposium USENIX Association  Event Type Label and Description 0x00000001 EV POST CODE This event must be extended to PCR #0. It is used to record power-on self test (POST) code, embedded SMM code, ACPI flash data, boot integrity services (BIS) code, or manufacturer-controlled embedded option ROMs. 0x00000004 EV SEPARATOR This event must be extended to PCR #0-PCR #7. It is used to delimit actions taken during the pre-OS and OS environments. In case of TPM 1.2, the digest field must contain a hash of the hex value 0x00000000 for UEFI firmware and 0xFFFFFFFF for BIOS. In case of TPM 2.0, the digest field must contain a hash of the hex value 0x00000000 or 0xFFFFFFFF for TPM 2.0. 0x00000008 EV S CRTM VERSION This event must be extended to PCR #0. It is used to record the version string of the SRTM. 0x0000000D EV IPL This event field contains IPL data. 0x80000001 EV EFI VARIABLE DRIVER CONFIG This event is used to measure configuration for EFI variables. The digests field contains the tagged hash of the variable data, e.g. variable data, GUID, or unicode string. 0x80000003 EV EFI BOOT SERVICES APPLICATION This event measures information about the specific application loaded from the boot device (e.g., IPL). 0x80000006 EV EFI GPT EVENT This event measures the UEFI GPT table. 0x80000008 EV EFI PLATFORM FIRMWARE BLOB This event measures information about non-PE/COFF images. The digests field contains the hash of all the code (PE/COFF .text sections or other sections). Table 3: Summary of event types that are frequently used [39] hash values left in the logs. After sleep, the values are re-extended to the PCRs by hooking the functions in the DCE and DLME. The result is the same as that of the SRTM exploit. 4.3.3 Implementation in Detail We explain how to reset the TPM state and counterfeit the PCR values. The tboot [11] is an open source im- plementation of Intel TXT that employs the notion of DRTM to support a measured launch of a kernel or a vir- tual machine monitor (VMM). It consists of the secure initialization (SINIT) ACM and tboot, which correspond to the DCE and DLME, respectively. In Intel TXT, the Compromised Software Stack Normal State (TPM shows normal PCRs) Leaves normal hashes in event logs BIOS/UEFI Sleep Sleep Compromised Software Stack Wake up Faked State (Still compromised but TPM shows the normal PCRs) Extract and calculate the normal hashes Hash values Store the normal hashes in RAM Reboot DCE and DLME Reset the TPM and replay the normal hashes with the hooked functions Hook function pointers in the DCE and the DLME Hooked functions Compromised State (TPM shows abnormal PCRs) DCE and DLME Figure 9: Exploit scenario for the DRTM vulnerability DLME is called the MLE. The steps of tboot are shown in Figure 10. The tboot part is loaded by a bootloader, together with a kernel or a VMM. When the bootloader transfers the control to tboot, its pre-launch part starts the SINIT ACM. It measures the MLE (tboot) and extends the mea- surements to the dynamic PCRs. SINIT ACM starts the post-launch part of tboot, it measures the DRTM com- ponents, and extends the dynamic PCRs according to either legacy PCR mappings or details/authorities PCR mappings. Legacy PCR mappings use PCR #17, PCR #18, and PCR #19 for extending the measurements of the launch control policy (LCP), kernel file, and initial RAM disk (initrd) file, respectively. Details/authorities PCR mappings use PCR #17 for the measurements of the LCP, kernel file, and initrd file. PCR #18 is reserved for mea- surements of the verification key for SINIT ACM and LCP. When exiting the S3 sleeping state, tboot restarts DRTM using the data loaded in the memory at the boot USENIX Association 27th USENIX Security Symposium 1237  !"#$%&'(")"*)+*",-"'&$%".,(&"%,"/01" !"#$&.2%&"'&$%".,(&" 3,,%4,)(&5" 67893:" ;<=</" >?1" [email protected]?#:" 05&" A)2'.*" ?,(&" B&5'&4" 3<C;D" 9#E<" 0?8"FGH" 0?8"FGHI0?8"FGJ" <'K%K)4"8>1" @K+L" A?0"K'" =M8>1" /01" 0,+%" A)2'.*" ?,(&" %N,,%"[email protected]#O"1A#:" ;#=/#8" [email protected]"#P&'%:" Figure 10: Steps of tboot time. This means that the process of measuring and ex- tending the kernel or the VMM can be interfered with by compromising the data loaded in the memory. After reviewing the source code of tboot, we found that some mutable function pointers that are not mea- sured open up a window of attack. Figure 11 shows the detailed process of the exploit for the DRTM vulnerabil- ity using mutable function pointers. According to Intel’s specification [14], SINIT ACM obtains a loaded address, a size, and the entry point of an MLE by reading the MLE header. The header should be placed inside the loaded MLE and measured by the SINIT ACM so that unauthorized modification of the header is not allowed. In the latest version of the tboot source code (1.9.6, at the time of this writing), the start and the end of an MLE ( mle start and mle end) are de- fined in the link script (as shown in Figure 12) includ- ing from the start of the code section (.text) to the end of the read-only data section (.rodata). Therefore, any alteration of those sections will be identified by the mea- surement extended by SINIT ACM. In contrast to the code and read-only data, the writable data section (.data) and the uninitialized data segment (the .bss section) are not measured. After careful investi- gations, we found that some variables (g tpm, tpm 12 if, and tpm 20 if, as shown in Figure 13) exist in the un- measured sections and could affect the control flow. The mutable variables are function pointers left behind and not measured. By hooking those pointers, we can hook the control flow and eventually forge the dynamic PCRs, bypassing the protections provided by the SINIT ACM. Similarly to the attack explained in Section 4.2, the normal measurements extended by tboot are recorded in the event logs that reside in the kernel’s memory area. The txt-stat tool provided by tboot dumps the kernel memory via /dev/mem and prints out the summary sta- tus of TXT and event logs, as shown in Figure A.1 in Appendix. After obtaining the normal digests, we can forge ex- tended values after tboot takes control by hooking the ex- !"##!$ %&#'!$()*+,-.$ !"#$%&!'())%)*+,"""# !"#$%-!'.)//"0&,"""# !"#$%*!'0)-1"231"""# """# /)'-$0)1*2'$3+$454$(#6'$ 456785'59:;<='>;59:' 456785'59:;<='59:;%3;<=' 456785'59:;<='59:;3.;<=' 7*+,!3#+$&#3+!28'$3+$!"##!$ 9.$:;!8),!$+#8<)1$-)'-2'$=8#<$ $$$$$!-2$454$1#6'$)+>$$ $$$$$=*+,!3#+$?#3+!28'$3+$!"##!$ @.$A)1,*1)!2$-)'-2'$#=$!-2$$ $$$$$+#8<)1$B28+21$%&AC$D9EF$ $$$$$&AC$D9G.$ !"##!$ %&82$()*+,-.$$ A-)+62$=*+,!3#+$?#3+!28'$!#$$ 2;!2+>$!-2$+#8<)1$-)'-2'$ 9.$C2'2!$>H+)<3,$&AC'$ @.$:;!2+>$)$!"##!$-)'-$ C2?1)H$!-2$+#8<)1$-)'-2'$I3!-$ -##B2>$=*+,!3#+$?#3+!28'$ JKLK4$MAN$ 9.$A-)+62$!-2$B28+21$ @.$C2"##!$!-2$'H'!2<$ L#8<)1$&AC'$ $%&'()*("""# +%,-.# """# """# -3%&.%+*"""# !"#$%&' 3+?1"2*&"""# !"#$%-' (22?(2-&"""# !"#$%*' """# """# ........"""# +%,-'/# OKPJQR:7K$ L#8<)1$O##!1#)>28$ L#8<)1$/)'-$0)1*2'$ !"#$%&!#())%)*+,"""# !"#$%-!#.)//"0&,"""# !"#$%*!#0)-1"231"""# """# 456785'59:;<='@AAB;>;59:' 456785'59:;<='@AAB;59:;%3;<=' 456785'59:;<='@AAB;59:;3.;<=' /##B2>$7*+,!3#+$&#3+!28'$3+$!"##!$ M"+#8<)1$&AC'$ %&AC$D9S$)+>$&AC$D9G$)82$>3==282+!$3+$126),H$&AC$<)??3+6'T$ )+>$&AC$D9E$3'$>3==282+!$3+$>2!)31'Q)*!-#83!32'$<)??3+6'.$$ $%&'()*("""# +%,-.# """# """# ("-,1&*0"""# !"#$%&' ?1"-//-?"""# !"#$%-' +2"0%13,"""# !"#$%*' """# """# ........"""# +%,-'/# A#<?8#<3'2>$U28+21$ !"##$% &'(#%)$% OKPJQR:7K$ !*%!"##$+,-%!.'.#% OKPJQR:7K$ !"##!$ %&#'!$()*+,-.$ !"##!$ %&82$()*+,-.$$ JKLK4$MAN$ A#<?8#<3'2>$U28+21$ L#8<)1$&AC'$ $%&'()*("""# +%,-.# """# """# -3%&.%+*"""# !"#$%&' 3+?1"2*&"""# !"#$%-' (22?(2-&"""# !"#$%*' """# """# ........"""# +%,-'/# /012'"%!.'.#% %4&N$'-#I'$+#8<)1$ &AC'.$ 302$102+4#5%!.'.#% %4&N$'-#I'$)"+#8<)1$ &AC'.$ 6'(#5%!.'.#% %J!311$,#<?8#<3'2>$ "*!$4&N$'-#I'$!-2$+#8<)1$ &AC'.$ Figure 11: Detailed process of exploiting the DRTM vul- nerability posed function pointers. The hook functions reside in the data section of tboot in shellcode form, and the hooking has to be done before the platform enters the S3 sleeping 1238 27th USENIX Security Symposium USENIX Association  SECTIONS { . = TBOOT_BASE_ADDR ; /* 0x800000 */ .text : { *(. tboot_multiboot_header ) . = ALIGN (4096); *(. mlept) _mle_start = .; /* Beginning of MLE */ *(. text) *(. fixup) *(. gnu.warning ) } :text = 0x9090 .rodata : { *(. rodata) *(. rodata .*) } . = ALIGN (4096); _mle_end = .; /* End of MLE */ .data : { /* Data */ *(. data) *(. tboot_shared ) CONSTRUCTORS } ... omitted ... } Figure 12: Sections in the link script (tboot.lds.x) of tboot state. The locations of g tpm, tpm 12 if, and tpm 20 if are as shown in Figure 13. The offsets might differ ac- cording to the versions of the implementation, but those function pointers are exposed in the mutable section. The last step of the attack, likewise, is to reset the TPM state and replay the normal digests. The difference is that, when the platform wakes up, tboot and SINIT ACM are executed. SINIT ACM resets the dynamic PCRs, measures tboot, and extends the measurements to PCR #17. It starts tboot again, and tboot extends the PCRs with the hook functions. The replay should be done by extending the measurements in the designated order for replacing the measurement of the customized kernel with the normal one. 4.4 Evaluation We tested our exploits on various Intel-based platforms to determine how many devices are exposed to these vul- nerabilities. The tested devices are listed in Table 4. Ubuntu 16.04.03 was used as the host operating sys- tem. The genuine kernel 4.13.0-21-generic of the op- erating system was used for our customization, in which we removed the TPM SaveState() or TPM2 Shutdown() calls. For the SRTM attack mentioned in Section 4.2, we used the source code of CoreOS GRUB 2.0 [5]. For the DRTM attack, we used source code from the tboot project [11]. The devices were UEFI booted from the ex- /* Beginning of text section (ready -only) */ 800000 t multiboot_header 800010 t multiboot2_header 800020 t multiboot2_header_end 801000 t g_mle_pt 804000 T _mle_start /* Beginning of MLE */ 804000 T _start 804000 T start 804010 T _post_launch_entry ... omitted ... 83 b000 D _mle_end /* End of MLE */ /* Beginning of data section (writable) */ 83 b000 D s3_flag ... omitted ... 83 f234 D g_tpm /* Current TPM interface */ ... omitted ... 83 f2c0 D tpm_12_if /* TPM interfaces in */ 83 f460 D tpm_20_if /* data section for */ /* TPM 1.2 and 2.0 */ ... omitted ... Figure 13: tboot symbols. The TPM interfaces are in the data section ternal hard disk drive, where we installed the customized system with exploits. To replace the normal bootloader and kernel with our customized ones, we put the cus- tomized ones under the /boot directory with the same name. TPM 2.0 supports multiple banks of PCRs, with each bank implementing different hash algorithms. The BIOS/UEFI firmware and the kernel are likely to be ex- tended to separate banks. Although the reported vulner- abilities do not depend on a specific hash algorithm, we used SHA-1 in all evaluations only because the algorithm is supported in both versions of the TPM. The DRTM exploit requires devices to support Intel TXT and tboot. However, some of them do not support Intel TXT and some of the TXT-supporting devices do not work with tboot, as a result, we could exploit only a few of them. Table A.1 in Appendix shows the tested devices. 4.4.1 SRTM Attack: Grey Area Vulnerability Table 5 compares all normal PCR values and exploited PCR values except for PCR #10, which is extended by IMA in the kernel. Although the PCR #10 values of all PCs are different, the value of PCR #10 can be extended from PCR #0-PCR #7. We hence attach additional tables in our GitHub repository [10], which lists the PCR values obtained from the normal SRTM-based booting sequence on our tested devices. Because the static PCRs values are measurements of the SRTM components, most of the values differ ac- cording to the manufacturers and model, except for PCR #4 and PCR #9, where the measurements of the boot- USENIX Association 27th USENIX Security Symposium 1239  PC No. Vendor CPU (Intel) PC and mainboard model BIOS Ver. and release date TPM Ver. TPM vendor and firmware Ver. SRTM attack 1 Intel Core i5-5300U NUC5i5MYHE MYBDEWi5v.86A, 2017.11.30 2.0 Infineon, 5.40 Y 2 Intel Core m5-6Y57 Compute Stick STK2mv64CC CCSKLm5v.86A.0054, 2017.12.26 2.0 NTC, 1.3.0.1 Y 3 Dell Core i5-6500T Optiplex 7040 1.8.1, 2018.01.09 2.0 NTC, 1.3.2.8 Y 4 GIGABYTE Core i7-6700 Q170M-MK F23c 2, 2018.01.11 2.0 Infineon, 5.51 Y 5 GIGABYTE Core i7-6700 H170-D3HP F20e, 2018.01.10 2.0 Infineon, 5.61 Y 6 ASUS Core i7-6700 Q170M-C 3601, 2017.12.12 2.0 Infineon, 5.51 Y 7 Lenovo Core i7-6600U X1 Carbon 4th Generation N1FET59W (1.33), 2017.12.19 1.2 Infineon, 6.40 N 3 8 Lenovo Core i5-4570T ThinkCentre m93p FBKTCPA, 2017.12.29 1.2 STMicroelectronics, 13.12 N 3 9 Dell Core i5-6500T Optiplex 7040 1.8.1, 2018.01.09 1.2 NTC, 5.81.2.1 N 4 10 HP Xeon E5-2690 v4 z840 M60 v02.38, 2017.11.08 1.2 Infineon, 4.43 N 3 11 GIGABYTE Core i7-6700 H170-D3HP F20e, 2018.01.10 1.2 Infineon, 3.19 N 3 Table 4: List of PC and mainboard models and results of the SRTM attack PC No. TPM Ver. PCR No. PCR values 5 of the ORIGINAL system PCR values of the COMPROMISED system PCR values after the SRTM attack 1-7, 1.2, 4 1C2549F2... DF5AD048... 1C2549F2... 9-11 2.0 9 7767E9EB... DA28F689... 7767E9EB... 8 6 1.2 4 849162AD... 9966FE5A... 849162AD... 9 7767E9EB... DA28F689... 7767E9EB... Table 5: Forged PCR values after the SRTM attack loader and kernel are extended. Interestingly, the Lenovo m93p machine (PC #8) has a different value for PCR #4, even though it uses the same bootloader. After looking into the event logs, the m93p machine uses a hash of 0xFFFFFFFF as the event separator...