In-depth dive into the security features of the Intel/Windows platform secure boot process
This blog post is an in-depth dive into the security features of the Intel/Windows platform boot process. In this post I’ll explain the startup process through security focused lenses, next post we’ll dive into several known attacks and how there were handled by Intel and Microsoft. My wish is to explain to technology professionals not deep into platform security why Microsoft’s SecureCore is so important and necessary.
Not exclusive to Windows systems, lots of PC platform details.
Booting from a vinyl record
So this nutty little experiment connects a PC, or an IBM PC to be exact, directly onto a record player through an amplifier. There is a small ROM boot loader that operates the built-in “cassette interface” of the PC (that was hardly ever used), invoked by the BIOS if all the other boot options fail, i.e. floppy disk and the hard drive. The turntable spins an analog recording of a small bootable read-only RAM drive, which is 64K in size. This contains a FreeDOS kernel, modified by me to cram it into the memory constraint, a micro variant of COMMAND.COM and a patched version of INTERLNK, that allows file transfer through a printer cable, modified to be runnable on FreeDOS. The bootloader reads the disk image from the audio recording through the cassette modem, loads it to memory and boots the system on it. Simple huh?
Avoiding gaps in IOMMU protection at boot
But setting things up in the OS isn’t sufficient. If an attacker is able to trigger arbitrary DMA before the OS has started then they can tamper with the system firmware or your bootloader and modify the kernel before it even starts running. So ideally you want your firmware to set up the IOMMU before it even enables any external devices, and newer firmware should actually do this automatically. It sounds like the problem is solved.
A Deep Dive Into Samsung's TrustZone
After a general introduction on the ARM TrustZone and a focus on Qualcomm’s implementation, this new series of articles will discuss and detail the implementation developed by Samsung and Trustonic.
These blog posts are a follow up to the conference Breaking Samsung’s ARM TrustZone that was given at BlackHat USA this summer. While an event such as this one is a great opportunity to present a subject we have been working on, many details have to be overlooked to fit the 50-minute format. This blog post, and the following ones, will explain all the details that were missing from the presentation as well as release the different tools mentioned in the talk and developed along the way.
TPM—Fail TPM meets Timing and Lattice Attacks
We discovered timing leakage on Intel firmware-based TPM (fTPM) as well as in STMicroelectronics’ TPM chip. Both exhibit secret-dependent execution times during cryptographic signature generation. While the key should remain safely inside the TPM hardware, we show how this information allows an attacker to recover 256-bit private keys from digital signature schemes based on elliptic curves.
This research shows that even rigorous testing as required by Common Criteria certification is not flawless and may miss attacks that have explicitly been checked for. The STMicroelectronics TPM chip is Common Criteria certified at EAL4+ for the TPM protection profiles and FIPS 140-2 certified at level 2, while the Intel TPM is certified according to FIPS 140-2. However, the certification has failed to protect the product against an attack that is considered by the protection profile.
OpenTitan - open sourcing transparent, trustworthy, and secure silicon
Today, along with our partners, we are excited to announce OpenTitan - the first open source silicon root of trust (RoT) project. OpenTitan will deliver a high-quality RoT design and integration guidelines for use in data center servers, storage, peripherals, and more. Open sourcing the silicon design makes it more transparent, trustworthy, and ultimately, secure.
Tethered jailbreaks are back
checkm8 exploits the Boot ROM to allow anyone with physical control of a phone to run arbitrary code. The Boot ROM, also called the Secure ROM, is the first code that executes when an iPhone is powered on and cannot be changed, because it’s “burned in” to the iPhone’s hardware. The Boot ROM initializes the system and eventually passes control to the kernel. It’s the root of trust for the trusted boot chain of iOS and verifies the integrity of the next stage of the boot process before passing execution control.
Detailed writeup: https://habr.com/en/company/dsec/blog/472762/
Understanding modern UEFI-based platform boot
To many, the (UEFI-based) boot process is like voodoo; interesting in that it’s something that most of us use extensively but is - in a technical-understanding sense - generally avoided by all but those that work in this space. In this article, I hope to present a technical overview of how modern PCs boot using UEFI (Unified Extensible Firmware Interface).
Quite the overview.
Adventures in reverse engineering Broadcom NIC firmware
The reverse engineering project, Project Ortega, began in December 2017 and involved reverse engineering proprietary firmware to determine what any open source replacement would need to do. Mainly this involved producing a reverse engineered C codebase from the disassembly of proprietary firmware, then producing a natural-language specification for others to reimplement; the actual reversed code itself is not published. In other words, this is a clean-room reverse engineering workflow.
An overview of Secure Boot in Debian
This blog post isn’t meant to be a definitive guide about Secure Boot in Debian. The idea is to give some context about the boot sequence on the PC architecture, about the Secure Boot technology, and about some implementation details in Debian.
Nevertheless, pretty complicated.
Thunderclap - Modern computers are vulnerable to malicious peripheral devices
We look at the security of input/output devices that use the Thunderbolt interface, which is available via USB-C ports in many modern laptops. Our work also covers PCI Express (PCIe) peripherals which are found in desktops and servers.
Such ports offer very privileged, low-level, direct memory access (DMA), which gives peripherals much more privilege than regular USB devices. If no defences are used on the host, an attacker has unrestricted memory access, and can completely take control of a target computer: they can steal passwords, banking logins, encryption keys, browser sessions and private files, and they can also inject malicious software that can run anywhere in the system.
We studied the defences of existing systems in the face of malicious DMA-enabled peripheral devices and found them to be very weak.
The primary defence is a component called the Input-Output Memory Management Unit (IOMMU), which, in principle, can allow devices to access only the memory needed to do their job and nothing else. However, we found existing operating systems do not use the IOMMU effectively.
Previous work: http://www.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/2018/MSC/MSC-2018-21.pdf
AWS Nitro System
The Nitro System supports key network, server, security, firmware patching, and monitoring functions freeing up the entire underlying server for customer use. This allows EC2 instances to have access to all cores – none need to be reserved for storage or network I/O. This both gives more resources over to our largest instance types for customer use – we don’t need to reserve resource for housekeeping, monitoring, security, network I/O, or storage. The Nitro System also makes possible the use of a very simple, light weight hypervisor that is just about always quiescent and it allows us to securely support bare metal instance types.
Deciphering the Messages of Apple’s T2 Coprocessor
To discover and communicate with advertised services, the T2 exposes itself to macOS as a network interface, assigned as en6 on our lab machines. This macOS interface is configured for IPv6 with a universally static local address of fe80::aede:48ff:fe00:1122. The T2 exposes itself at a fixed IPv6 address of fe80::aede:48ff:fe33:4455.
MacOS and the T2 communicate over a typical network stack, with a few notable exceptions. Ethernet frames are encapsulated within Mobile Broadband Interface Model (MBIM) packets for transmission over what we can therefore infer is a USB-based interface. For simple application-level messages, one MBIM frame will typically contain a single message, but for larger data transfers, multiple Ethernet frames will be encapsulated within each packet. This is somewhat ironic, as often a data transfer segment will be split into MTU-sized chunks at the TCP layer, only to be combined into a single packet at the MBIM layer.
Above the TCP/IP layer, macOS and the T2 use the HTTP/2 protocol to open, and often maintain, persistent connections between different applications
Announcing coreboot 4.9
In the little more than 7 months since 4.8.1 we had 175 authors commit 2610 changes to master. The changes were, for the most part, all over the place, touching every part of the repository: chipsets, mainboards, tools, build system, documentation.
Secure Boot in the Era of the T2
Today, we are continuing our series on Apple’s new T2 platform and examining the role it plays in Apple’s vision of Secure Boot. The T2 was first introduced with the release of the iMac Pro and has now found its way into every new 2018 Macbook Pro. This article covers the security properties and technical implementation details of what makes this platform unique.
A major and the most significant approach to UEFI BIOS security is to prevent it from being illegitimately modified and the SPI flash memory from being overwritten. Modern vendors use a wide range of security mechanisms to ensure that (SMM BLE / SMM BWP / PRx / Intel BIOS Guard) and hardware-supported verification technologies (Intel Boot Guard). In other words, they do everything just not to let an attacker place a rootkit into a system.
In this talk, there were some thoughts on how vendors manage to throw all those security flaws together in one system using Intel NUC, a small home PC, as an example. Besides, researchers demonstrated how an adversary can compromise BIOS from the userland.
Turning your BMC into a revolving door
Baseboard Management Controller (BMC) embedded in most of HP servers for more than 10 years. Chipset directly integrated on the server’s motherboard.
There’s a computer inside your computer.
Intel ME Manufacturing Mode: obscured dangers and their relationship to Apple MacBook vulnerability CVE-2018-4251
Intel ME Manufacturing Mode is intended for configuration and testing of the end platform during manufacturing, and as such should be disabled (closed) before sale and shipment to users.
This mode allows configuring critical platform settings stored in one-time-programmable memory (FUSEs). These settings include those for BootGuard (the mode, policy, and hash for the digital signing key for the ACM and UEFI modules). Some of them are referred to as FPFs (Field Programmable Fuses).
We analyzed several platforms from a number of manufacturers, including Lenovo and Apple MacBook Prо laptops. The Yoga and ThinkPad computers we examined did NOT have any issues related to Manufacturing Mode. But we found that Apple laptops on Intel chipsets are running in Manufacturing Mode. After this information was reported to Apple, the vulnerability (CVE-2018-4251) was patched in macOS High Sierra update 10.13.5.
Intel patches new ME vulnerabilities
CVE-2018-3627, the vulnerability at issue in advisory SA-00118, is described as a logic bug (not a buffer overflow) that may allow execution of arbitrary code. Ease of exploitation makes this vulnerability more dangerous than the one in SA-00086, which was locally exploitable only in case of OEM configuration errors; instead, an attacker simply needs local access.
Things are even worse with CVE-2018-3628, which is described in advisory SA-00112. This vulnerability enables full-blown remote code execution in the AMT process of the Management Engine. Moreover, all signs indicate that—unlike CVE-2017-5712 in advisory SA-00086—attackers do not need an AMT administrator account.
Insider Attack Resistance
To mitigate these risks, Google Pixel 2 devices implement insider attack resistance in the tamper-resistant hardware security module that guards the encryption keys for user data. This helps prevent an attacker who manages to produce properly signed malicious firmware from installing it on the security module in a lost or stolen device without the user’s cooperation. Specifically, it is not possible to upgrade the firmware that checks the user’s password unless you present the correct user password.