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.
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.
Intel Warns Its Patches for Chip Flaws Are Buggy
> One Intel partner familiar with the document said it is problematic the company is only notifying select customers they should hold off on the patches. The public has “been given the microcode update but has not been given the important technical information that Intel recommends that you don’t use this,” the partner said.
Sigh. Maybe don’t rush to install that bios update.
AMD-PSP: fTPM Remote Code Execution via crafted EK certificate
> AMD PSP  is a dedicated security processor built onto the main CPU die.
ARM TrustZone provides an isolated execution environment for sensitive and
privileged tasks, such as main x86 core startup.
The Intel ME vulnerabilities are a big deal for some people, harmless for most
Some plain English analysis.
Running Unsigned Code In Intel ME