Author: hucktech

NetCAT shows that network-based cache side-channel attacks are a realistic threat. Cache attacks have been traditionally used to leak sensitive data on a local setting (e.g., from an attacker-controlled virtual machine to a victim virtual machine that share the CPU cache on a cloud platform). With NetCAT, we show this threat extends to untrusted clients over the network, which can now leak sensitive data such as keystrokes in a SSH session from remote servers with no local access. The root cause of the vulnerability is a recent Intel feature called DDIO, which grants network devices and other peripherals access to the CPU cache. Originally, intended as a performance optimization in fast networks, we show DDIO has severe security implications, exposing servers in local untrusted networks to remote side-channel attacks.

Intel agrees this is a significant vulnerability, having awarded NetCAT a bounty and recommending users to “limit direct access from untrusted networks when DDIO & RDMA are enabled“. This essentially means that in untrusted network environments DDIO and/or RDMA should be disabled to provide security. To the best of our knowledge, this is the first time a major hardware vendor like Intel cautions against using a CPU feature in untrusted local networks.

William Leara, a UEFI firmware engineer, has a new blog post giving a roadmap to the TCG’s TPM specs:

A Roadmap to TCG’s TPM Documentation: The Trusted Platform Module (TPM) found in most computers today is a device governed by the specifications of the Trusted Computing Group (TCG). Truly grokking how a TPM operates is a daunting task: the specification for the TPM, called the TPM Library Specification, currently comes in four parts, totaling 2237 pages. (!) However, even those 2237 pages aren’t the whole story. This article provides a roadmap to the various specifications that define the TPM, in order to provide the reader with a comprehensive picture of what documentation is available, and what must be studied to acquire TPM mastery.[…]

We have been promoting the benefits of our PureBoot tamper-evident firmware with a Librem Key for some time, but until now our laptops have shipped with standard coreboot firmware, that didn’t include tamper-evident features. To get tamper-evident features, you had to reflash your Librem laptop with PureBoot firmware after the fact, using our standard firmware update process. One of the biggest challenges for most people using PureBoot was the initial setup process–but many people might find installing an OS challenging too. The best way to solve this challenge is for us to do the setup for you–and that’s what we are happy to announce today.[…]

When you boot up any device, that jump rom a powered-down processor to a device running trusted software requires hardware support. The old Basic Input/Output System (BIOS) of over 30 years ago didn’t provide any protections — it could barely get an operating system loaded. Since then, system vendors have been trying to build more security into the boot process. Industry-standard approaches such as Unified Extensible Firmware Interface (UEFI) have set the groundwork and created best practices. Today, smartphones need that same protection. The Android community has specified some starting points, but device vendors, such as Samsung, have built on those to bring smartphone security to “enterprise-ready” levels. The end goal is to make sure the smartphone is running trusted software. Two components helping ensure that are secure booting with Samsung Trusted Boot and kernel integrity checking through TrustZone-based Integrity Management Architecture (TIMA).[…]

I got a super nice project, and for that I needed to learn how the SMM really works. Again I started dipping my toes in this ocean of knowledge and I hope I don’t get too excited and drown myself before even getting started 😉 For the people who are not sure if they want to read all this: In SMM, it is possible to modify SMM saved execution context. SMM also sets its own IDT, it is initialized by the BIOS (DXE) and tons of cool stuff. Normally, CS base address is system-management RAM (SMRAM) base address and SMM code is copied to SMRAM in UEFI initialization and SMRAM is locked right after for security reasons. […]

We're building *really* well engineered demos of Spectre, Meltdown, and any other SW side-channel vulns that we need to defend against. Make them repeatable and understandable. But not weaponized.@mdriley25519

[…]In this paper, we discuss an attack that borrows concepts from the evil maid. We assume exploitation can be used to infect a bootloader on a system running macOS remotely to install code to steal the user’s password. We explore the ability to create a communication channel between the bootloader and the operating system to remotely steal the password for a disk protected by FileVault 2. On a macOS system, this attack has additional implications due to “password forwarding” technology, in which a user’s account password also serves as the FileVault password, enabling an additional attack surface through privilege escalation.[…]

UEFI OVMF symbol load script for GDB: GDB extension to automate loading of debug symbols for OVMF image. Also works for custom drivers and applications, as long as symlinks to .efi and .debug files are present in working directory. Sourcing script from gdb adds new command “efi”.

We've finally managed to update our Secure Boot Technical Overview to cover the enhancements from the last couple of years (h/t @NAKsecurity for the excellent initial document). Find this and a whitepaper on secure storage in TrustZone at https://t.co/WmUupKf5uH.

[…]In 2017, we released our first public whitepaper describing the philosophy and implementation of the Qualcomm Technologies’ Secure Boot solution. Since then, the solution has been improved and we are pleased to make available a new release of the “Secure Boot and Image Authentication” technical overview whitepaper.[…]

[…]This tool requires a rom library dump from the ME to use. See https://github.com/ptresearch/IntelTXE-PoC for a means of acquiring one, though that will yield a ROM for a different chipset (BXT). That chipset shares most core ME peripherals with SPT so changing the code will mostly mean tweaking addresses.

Rewrote most of my ME emulator code to allow targeting different chipsets by introducing a configuration system. I also switched from static MMIO decoding to bus emulation. This rewrite is now as functional as the orig. release, and is at https://t.co/89apL9ii8N