Securing the EDK II Image Loader
Total Page：16
File Type：pdf, Size：1020Kb
Securing the EDK II Image Loader Marvin Hauser¨ Vitaly Cheptsov Technische Universitat¨ Kaiserslautern; Ivannikov Institute for System Programming Ivannikov Institute for System Programming of the Russian Academy of Sciences of the Russian Academy of Sciences Moscow, Russia Kaiserslautern, Germany [email protected] [email protected] Abstract—The Unified Extensible Firmware Interface (UEFI) UEFI for image signature is Microsoft Authenticode [5], which is a standardised interface between the firmware and the op- bundles image signature within the PE file and requires most erating system used in all x86-based platforms over the past of structural parsing for its verification. While the choice of ten years, which continues to spread to other architectures such as ARM and RISC-V. The UEFI incorporates a modular this algorithm made it possible to reuse the code signing tools design based on images containing a driver or an application also used for Windows driver signing easing the development in a Common Object File Format (COFF) either as a Portable process, it also imposed a number of extra security require- Executable (PE) or as a Terse Executable (TE). The de-facto ments on the software in charge of the signature verification standard generic UEFI services implementation, including the process on the firmware side. image loading functionality, is TianoCore EDK II. Its track of security issues shows numerous design and implementation Today most of the platform-independent code of the flaws some of which are yet to be addressed. In this paper we UEFI firmwares is implemented as part of the open-source outline both the requirements for a secure UEFI Image Loader TianoCore EDK II [6] toolkit. This implementation consisting and the issues of the existing implementation. As an alternative of about a million lines of C code also includes the code to we propose a formally verified Image Loader supporting both handle the PE images that can be found in practically any mod- PE and TE images with fine-grained hardening enabling a seamless integration with EDK II and subsequently with the ern firmware. In an attempt to make the implementation more other firmwares. reliable contributions to EDK II go through a thorough review Index Terms—UEFI, Parsing, Security, Program verification. process backed with additional specifications covering the development from architecture to code style, automated testing I. INTRODUCTION on several platforms and on-demand testing with several static The fast spread of the Unified Extensible Firmware Inter- and dynamic analysers [7]. The amount of vulnerabilities face (UEFI) [1] over x86-based platforms would not have found in modern firmwares over the last ten years shows been possible without the adoption of other specifications that the measures taken are clearly not enough [8]. While backed with existing widely available tools. The use of the the attempts to introduce other programming languages with Portable Executable (PE) [2] format let Intel reuse the existing built-in safety checkers may improve the situation with naive specification for the format itself as well as the established security issues like buffer overflows, logic errors are much compiler infrastructure. This decision led the UEFI Forum to harder to find and in general cannot be identified automatically. keep including the PE format as part of the UEFI specification In this paper we suggest using formal verification to se- essentially making it the core of the UEFI modular architec- cure the PE image loading functionality in UEFI. Section II ture. describes the issues of the current implementation present in The UEFI architecture is designed in a way that not all EDK II and specifications separating design defects, functional arXiv:2012.05471v2 [cs.CR] 3 Jun 2021 the modules used during the boot sequence can be equally defects, and potential issues not covered by the existing trusted. While firmware module trust is assumed as a fact implementation. Section III provides a basic introduction into by the UEFI and UEFI PI [3] specifications and is handled formal verification and introduces AstraVer, the tool we used by vendor-specific technologies such as Intel BootGuard [4], to verify the code against our models. Section IV describes other module protection is not taken for granted and is the implementation and the verification model. part of the “Secure Boot and Driver Signing” and “Secure Note: We would like to clarify on our terminology to avoid Technologies” sections of the UEFI specification. ambiguities. Please note that specific terms from the cited A driver coming with an option ROM, a UEFI application, specifications will not be repeated. or a standalone UEFI driver are by all means less trusted but • “[Raw] file” shall mean the format in which a PE or TE usually do not execute with significantly reduced privileges image is saved on storage devices. compared to firmware drivers and applications. To circumvent • “[Loaded] image” shall mean the format of a PE or TE this disadvantage each module external to the firmware is image expanded into the execution environment. verified to belong to an authority that is trusted by the firmware • “Verification” shall mean the process of ensuring the prior to execution. The standardised verification algorithm in plausibility of data structures within a file or image M. Hauser¨ and V. Cheptsov, ”Securing the EDK II Image Loader,” 2020 Ivannikov Ispras Open Conference (ISPRAS), 2020, pp. 16-25, DOI: 10.1109/ISPRAS51486.2020.00010. © 2020 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works. conforming to the PE format [2]. environment (UEFI protocol installation). Consequently, • “Hashing” shall mean the cryptographic hashing of the the Image Loader locates and exposes the location of this raw file data in a way described in the used signature data7. However, no verification occurs within or outside verification algorithm such as Authenticode [5]. the Image Loader before the data is exposed at load time8. • “Loading” shall mean the transformation of a TE or PE Loading an image cannot be seen as an act of trusting it, raw file into a loaded image. as with a safe loader implementation the image did not • “Relocating” shall mean rebasing a loaded image from yet gain or was given any control over the system. one virtual address base to another. This defect needs to be addressed on UEFI specification • “Image Loader” shall mean the library that performs level. actions such as verification, hashing, loading or relocating 4) Ambiguous context ownership of a raw file or image. Traditionally, context instances are owned by the library that declares them — coming from an object-orientated II. STATE OF THE ART programming paradigm, they can be thought of as non- The EDK II Image Loader contains various defects. While static members of a class instance. While public reading some are bugs of the specific implementation (“functional can be tolerated to simplify the interface, writes should defects”), others are fundamental design flaws of the library be performed strictly within the library implementation design that significantly raise the risk of introducing functional to preserve consistent states. EDK II currently relies on defects (“design defects”). external context writes as part of the library function 9 A. Design defects contracts . This defect is addressed by hardened design (IV-D). 1) Time-of-check/Time-of-use vulnerable design 5) Complicated function contracts The EDK II Image Loader uses a function provided by Function contracts should be easy to understand and the caller to abstract the gradual image data reading1. control flows easy to comprehend. Presently EDK II As made clear by the function specification its explicit relies on explicitly declaring the context fields required purpose is to allow arbitrary, untrusted data sources such to be valid and the context fields ensured to be valid as networks. At the time of writing there are a total by each function10. Except for fields explicitly allowed of 18 calls to this function across multiple stages of to be publicly read this severely overcomplicates the loading which makes ensuring data is not re-read and documentation. used unverified (TOC/TOU) a non-trivial task. This is This defect is addressed by hardened design (IV-D). currently an actual threat as the image headers are read 6) Decentralisation of code early for verification2 and then again when loading the There are several locations throughout the EDK II code- image into its final memory destination3 without ensuring base that access PE and TE image structures directly equivalence or re-verifying the data read. Whether this is instead of utilising the Image Loader11. This is strongly an actual security vulnerability depends on whether the undesired especially for the hashing algorithm which is caller-provided read function uses a trusted source (e.g. present four times12 outside the Image Loader, where the main memory) or not (e.g. network). function logically belongs. Without the library explicitly This defect is addressed by hardened design (IV-D). expressing the guarantees it makes regarding image data 2) Out-of-bounds vulnerable design structures (as opposed to only its own context structure) HII data that is provided to the caller4 is variably-sized. the code cannot trust the structures. Validating them Since its internal offsets are not validated to be in bounds then may lead to code duplication depending on the of the image address space and it is also not stored with library implementation details. Furthermore, the Image the maximum bounds, so that it can be safely accessed5, Loader is exposed via two separate libraries13 for no the caller is left at a high risk of an out-of-bounds access.