AMD PSP vuln: fTPM remote code execution

Busy year for processor security so far…

AMD-PSP: fTPM Remote Code Execution via crafted EK certificate

From: Cfir Cohen via Fulldisclosure <fulldisclosure () seclists org>
Date: Wed, 3 Jan 2018 09:40:40 -0800

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 fTPM trustlet code was found in Coreboot’s git repository [5] and in several BIOS update files. […] This research focused on vendor specific code that diverged from the TCG spec. […] As far as we know, general exploit mitigation technologies (stack cookies, NX stack, ASLR) are not implemented in the PSP environment. […] Credits: This vulnerability was discovered and reported to AMD by Cfir Cohen of the Google Cloud Security Team.

09-28-17 – Vulnerability reported to AMD Security Team.
12-07-17 – Fix is ready. Vendor works on a rollout to affected partners.
01-03-18 – Public disclosure due to 90 day disclosure deadline.

Purism replies on CHIPSEC failures, adds TPM add-on, starts Heads work


Purism responds to the CHIPSEC failures here:

They also point out in that forum, and here:

that Purism is getting ready to start using Heads payload. They’ve been talking about it for months, maybe it’ll be a real option for upcoming Librem customers? I’m very excited to see a Heads system available by an OEM, instead of DIY and not an easy task.

And they’re adding a TPM as an ‘add-on’ to existing Librem laptops. Heads needs TPM for it’s measurements. (Hmm, I thought TPMs were an integral and tamper-resistant part of the system, and something that could be added on for trust was called a smartcard, but ok. I guess you have to solder the HW to the system. I presume attackers will be ordering spare add-ons so they can swap out units.)

In the above Purism forum, there was this user comment:

“I like the idea of putting a demo Librem notebook to a BlackHat conf where they try to break into the devices. Would be a nice test and a good commercial for you.”

They cannot do that with current Librem models. 🙂 This will need to wait for TPMs to be pre-installed and Heads as the payload.

This response from the above Purism forum seems a bit invalid:

“So there’s no way to access a BIOS menu to change the boot sequence (boot from USB) or set a machine password etc?”

“No, there is no such thing. The BIOS boots into your machine in roughly 450 milliseconds, there is no support for a menu, there is no time even for the user to press a key on the keyboard to enter a menu. The idea of coreboot is to do the minimum hardware initialization and then go to a payload. In our case, we use SeaBIOS which itself will initialize the video card and show the splash screen logo, and wait for 2 seconds for you to press ESC to show you the boot menu and let you choose your device (otherwise, it just boots to the default one). The boot choice isn’t saved, it’s just a boot override. If you want to change an option in coreboot, you need to change the config in the source and recompile coreboot then reflash it. If you want to change the boot order, you need to change the boot order in a file embeded in the flash, then reflash the BIOS.”

Yes, there is thing, which the reply says does not exist then a few sentences later explains that it does exist. The BIOS menu to change the boot order is available to anyone with physical access to the system, and presses the ESC key within 2 seconds of poweron. The unprotected BIOS and MBR-based hard drive can be quickly overwritten with malware on the attacker’s boot thumbdrive. Attendees of ‘a BlackHat conf’ will have such skills. 🙂

Purism is spending all their time undoing Intel’s features — Intel ME, Intel FSP, and now re-embracing older features — Intel TPM. Intel SMM is still an issue, STM is not being used by Purism. Intel ME may be disabled, but it’s a black-box device, who knows when attackers will start reactivating it and putting their malware-based version of Minix on that chip? You’re going to need tools to detect if ME is really disabled. I hope Purism’s roadmap has a RISC-V chip-based laptop in it, so they can stop fighting Intel features and have a fully-open stack. If they keep fighting the Intel stack, I hope they add the ‘stateless laptop’ that Joanna has proposed to their roadmap:

It might be useful to add coreboot Verified Boot to help secure their SeaBIOS payload, but that could probably only secure PureOS, and distro hoppers will have no benefit. But I don’t think Heads and Verified Boot are compatible? SeaBIOS also has TPM support, that’d be nice to see those measurements used, if they are embracing a TPM. And now that they have a TPM, they can start using Intel TXT too. 🙂

I am a little perplexed about Purims customer audience, who is concerned about privacy, and yet has so little concern for security, in exchange for the convenience feature of being easy to distro-hop. Anyway, if you want security, wait for the TPM and Heads to be integrated with future Librems.

more on Infineon TPM issue

The UK gov guidance was also recently updated, so maybe worth a re-read:

Encryption chip flaw afflicts huge number of computers

xen-uefi: Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

Instructions and tools to boot Xen in UEFI mode with TPM measurements of Xen and dom0

This repository contains tools and instructions for installing Xen and dom0 with UEFI/SecureBoot such that all critical components of Xen and the dom0 kernel get SecureBoot verified and measured into the TPM.

Includes an updated Shim.

Linux Security Summit 2017 Summary

James Morris summarized the recent LSS event, excerpts below. For full message, see his original oss-security list posting.

The 2017 Linux Security Summit (LSS) was held on Sept 14th and 15th in Los Angeles, USA. It was co-located with Open Source Summit North America (previously/including LinuxCon) and the Linux Plumbers Conference (LPC). LSS is unique as a security conference as it’s dedicated to Linux and Open Source, and tends to be focused on defensive security engineering. This year we had refereed presentations, Linux kernel security subsystem updates, and BoF topics. There was also a shared day with LPC (on the 13th), where the TPMs and containers microconfs were held. We’re also seeing continued activity in TPMs (v2.0 stack developoment), integrity/boot verification, hardware-based mitigations, mobile/device, and containers. There are lots of challenges across these areas, and the materials I’ve linked from LSS and LPC are a good place to start if you’re interested in where things are at currently. There was no video this year, unfortunately, and we’ll work on making that happen for next year. (in some cases by clicking on the session topics).

Insyde Software security updates for Windows 10

Hurray, UEFI vendors focusing on security! 🙂

Insyde® Software Highlights Strategies to Strengthen Firmware Security at the Fall UEFI Plugfest

Company’s Chief Technology Officer to Present at The UEFI Forum Plugfest in Taipei, Taiwan

[…]In related UEFI-security news, Insyde Software announced its full compliance with the latest firmware security updates needed by Microsoft’s upcoming Windows® release. The Windows 10 Fall Creators Update adds new requirements that include improved support for TPMs (Trusted Platform Modules) and new functionality for Secure Boot BIOS update, all of which is fully supported by InsydeH2O® UEFI BIOS.[…]

more on Infineon TPM issue


Chipsec v1.3.4 released

New or Updated Functionality:
* Updated support for 7th/8th generation Intel processors
* Added ability to undefine a configuration entry
* Added HAL and utilcmd for TPM Event Log
* Added utilcmd for TPM commands
* Added support for Apollo Lake
* added utilcmd to inspect PCI command/control registers


more on Infineon TPM issue

Simple PowerShell script to check whether a computer is using an Infineon TPM chip that is vulnerable to CVE-2017-15361.

Windows tool that analyzes your computer for Infineon TPM weak RSA keys (CVE-2017-15361)

Infineon Embedded Linux TPM Toolbox 2 (ELTT2) for TPM 2.0

Google response:

Toshiba response:

Lenovo response:

HPE response:

more on Infineon TPM issue (ROCA)

ROCA: Vulnerable RSA generation (CVE-2017-15361)

A newly discovered vulnerability in generation of RSA keys used by a software library adopted in cryptographic smartcards, security tokens and other secure hardware chips manufactured by Infineon Technologies AG allows for a practical factorization attack, in which the attacker computes the private part of an RSA key. The attack is feasible for commonly used key lengths, including 1024 and 2048 bits, and affects chips manufactured as early as 2012, that are now commonplace. Assess your keys now with the provided offline and online detection tools and contact your vendor if you are affected. Major vendors including Microsoft, Google, HP, Lenovo, Fujitsu already released the software updates and guidelines for a mitigation. Full details including the factorization method will be released in 2 weeks at the ACM CCS conference as ‘The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli’ (ROCA) research paper.


OpenXT has a nice article on Xen, Linux, TPM, and TXT. It also mentions the OpenXT toolkit.

OpenXT is an open-source development toolkit for hardware-assisted security research and appliance integration. Released as Open-Source Software (OSS) in June 2014, OpenXT stands on the shoulders of Xen Project and OpenEmbedded. It is derived from XenClient XT, which was first released in May 2011. It includes hardened Xen VMs that can be configured as a user-facing virtualization appliance, for client devices with Linux and/or Windows guests. It has been used to develop managed software appliances to isolate demanding graphics workloads, untrusted workloads and multiple networks on a single laptop or desktop. OpenXT is optimized for x86 devices with Intel VT-d, TXT (Trusted Execution Technology) and a TPM. OpenXT is being developed to meet the varied needs of the security and virtualization communities, as a toolkit for the configurable disaggregation of operating systems and user workflows. Client appliances developed on OpenXT can contain a mixture of open-source and proprietary software, supporting a range of business models.[…]


more on Infineon TPM issue

Re: the recent Infineon TPM problem, more and more downstream problems are being discovered. The main news presses have lots of stories on this now.


ChromeOS impact of Infineon TPM problem

More on:

“You can check the TPM firmware running on your device by looking at the firmware_version line of the tpm_version entry in chrome://system. If the tpm_version entry is absent, this is likely because you are running an old Chrome OS version which doesn’t report this information. Upgrade to a newer version and check again.”


Infineon TPMs generating weak keys?

ADV170012 | Vulnerability in TPM could allow Security Feature Bypass – A security vulnerability exists in certain Trusted Platform Module (TPM) chipsets. The vulnerability weakens key strength. It is important to note that this is a firmware vulnerability, and not a vulnerability in the operating system or a specific application. After you have installed software and/or firmware updates, you will need to re-enroll in any security services you are running to remediate those services.

Nice, Microsoft makes you agree to a EULA before you can view the web page. 😦


TCG announces DICE Architecture


Trusted Computing Group has released the Device Identifier Composition Engine (DICE) Architecture for securing resource-constrained devices that make up the Internet of Things. The DICE Architecture provides critical security and privacy benefits to IoT and embedded systems where traditional Trusted Platform Modules (TPM) may be impractical, while also enabling support for those devices with a TPM for additional security benefits. Security capabilities this new approach enables include strong device identity, attestation of device firmware and security policy, and safe deployment and verification of software updates, which often are a source of malware and other attacks. The DICE Architecture, with its hardware root of trust for measurement, breaks up the boot process into layers, and creates unique secrets and a measure of integrity for each layer. This means if malware is present, the device is automatically re-keyed and secrets are protected. […]

TPM microconf at 2017 Linux Plumbers Conference

Matthew Garrett has announced a TPM microconference at the upcoming Linux Plumbers Conference:

I’m pleased to say that after the success last year, there will be another TPM microconference at this year’s Linux Plumbers Conference. The current schedule has this taking place on Wednesday the 13th of September, so just under 4 weeks from now. We have a list of proposals for discussion at but please feel free to add more! I intend to finalise the schedule by the end of next week, so please do so as soon as you can. For those of you who weren’t there, the Linux Plumbers conference is an event dedicated to bringing together people working on various infrastructural components (the plumbing) of Linux. Microconferences are 3 hour long events dedicated to a specific topic, with the focus on identifying problems and having enough people in the room to start figuring out what the solutions should be – the format is typically some short presentations coupled with discussion.

From James Bottomley’s comments on the LPC entry on this microconf:

Following on from the TPM Microconference last year, we’re pleased to announce there will be a follow on at Plumbers in Los Angeles this year. The agenda for this year will focus on a renewed attempt to unify the 2.0 TSS; cryptosystem integration to make TPMs just work for the average user; the current state of measured boot and where we’re going; using TXT with TPM in Linux and using TPM from containers.

Full text of Matthew’s email:

APT monitoring & analysis …below Ring 0

Applying Provenance in APT Monitoring and Analysis Practical Challenges for Scalable, Efficient and Trustworthy Distributed Provenance
Jenkinson G, Carata L, Bytheway T, Sohan R, Watson RNM, Anderson J, Kidney B, Strnad A, Thomas A, Neville-Neil G

[…] Below Ring 0 – hardware primitives can potentially support provenance capture in a number of ways. Trusted Computing primitives such as Intel SGX (Software Guard Extensions) can be used provide stronger non-repudiation (even in the presence of a compromised OS). And new hardware primitives could directly support provenance capture, for example providing an append only log for use by the kernel to store provenance records prior to sending over a network.[…]

Matthew on improving UEFI Secure Boot on Linux with TPMs

CMC-Vboot: investigates Chrome’s Verified Boot

This project takes Chrome’s Verified Boot (Vboot) process and examines its various security properties using formal logic. This verification is done with a focus on the firmware/hardware boundary. The Vboot process depends on the correct functionality of a Trusted Platform Module (TPM) and a SHA accelerator. Because these hardware accelerators are interacted with through Memory Mapped I/O (MMIO), it is difficult for normal formal methods to capture the interface between the MMIO registers and the workings of the Hardware modules. To explore this boundary I am using a Software TPM Library and passing it through to the QEMU Hardware Emulator. This allows me to use the normal MMIO registers of a TPM with the original Vboot Library.[…]