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

Re: https://firmwaresecurity.com/2017/11/15/purism-librem15-fails-chipsec-security-tests/

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.



Toms Hardware: Win10 unsupported disk layout UEFI error howto

Tom’s Hardware – an example of a computer review site that never shows CHIPSEC results 😦 — has a new article on how to fix a common UEFI/Windows problem:

How To Fix Windows 10 Unsupported Disk Layout UEFI Error
by Seth Colaner November 17, 2017 at 1:30 PM

A common problem that Windows users have encountered when trying to update Windows 10 is the “Unsupported Disk Layout for UEFI Firmware” error. This error basically means that the partition structure of your hard drive is not supported by the version of Windows 10 that you want to upgrade to. This error can be resolved by creating a Microsoft Reserved Partition (MSR), which is used on Unified Extensible Firmware Interface (UEFI)/GUID Partition Table (GPT) disks. Without getting too technical, we will outline the steps to fix this error when attempting to update.[…]


PS: Tom, please start showing CHIPSEC (and FWTS) results in your reviews, less on what colors the cases come in, and more on what security the HW/FW fails to offer. Thanks!


FWTS 17.11.00 released (and added to LUV)

The November 2017 release of FirmWare Test Suite is out, with many ACPI changes, and a few UEFI changes.

New Features:
* acpi: devices: add a new test for acpi ec device
* acpi: devices: add a new test for ACPI AC adapter device
* acpi: devices: add a new test for ACPI battery device
* acpi: devices: add a new test for smart battery device
* acpi: devices: add new tests for power and sleep button devices
* acpi: madt: check GICD’s system vector according to mantis 1819 (ACPI 6.2a)
* acp: nfit: add platform capability according to manit 1831 (ACPI 6.2a)
* lib: add new large resource data type for _CRS methods
* acpi: sdev: add ACPI SDEV test (mantis 1632)
* acpi: dppt: add ACPI PDTT test (mantis 1576)
* acpi: devices: add new tests for lid device
* acpi: devices: add new tests for ambient light sensor device
* acpi: devices: add new tests for time and alarm device
* acpi: devices: add new tests for wireless power calibration device
* acpi: add tests for _SRT control method
* auto-packager: mkpackage.sh: add bionic
* fwts: add bash command-line completion
* Add ACPI 1.0 RSDP test to make sure RSDT field isn’t null
* ACPICA: Update to version 20171110
* uefi: uefidump: add dumping for BluetoothLE device path
* uefi: uefidump: add dumping for DNS device path
* uefi: uefibootpath: add test for BluetoothLE device path
* uefi: uefibootpath: add test for DNS device path


See full announcement for list of few-dozen bugfixes.

Full announcement:

In related news,  Gayatri Kammela has added this updated FWTS to LUV.

Update FWTS to version v17.11.00

Full patch:


DJI drone firmware exposes private keys on Github for years

As reported by the Register, security researcher Kevin Finisterre discovered the Chinese firm had left the private keys of the DJI HTTPS domain on GitHub, exposed for all to see for roughly four years. To make matters worse, DJI had also made AWS credentials and firmware AES keys available for anyone to search for through the GitHub repository.[…]Earlier this year the US Army issued a blanket ban on the use of DJI products by its personnel. It gave no reason for doing so, other than unspecified “cyber vulnerabilities,” and was rapidly followed in doing so by the Australian military. Several British police forces also use DJI drones for operations, in place of helicopters.[…]





US-CERT ST17-001: Securing the IoT

Security Tip (ST17-001):  Securing the Internet of Things
The Internet of Things is becoming an important part of everyday life. Being aware of the associated risks is a key part of keeping your information and devices secure. The Internet of Things refers to any object or device that sends and receives data automatically through the Internet. This rapidly expanding set of “things” includes tags (also known as labels or chips that automatically track objects), sensors, and devices that interact with people and share information machine to machine.[…]



Kaspersky 2018 Threat Predictions: Sophisticated UEFI and BIOS attacks

Kaspersky Security Bulletin: Threat Predictions for 2018
Juan Andrés Guerrero-Saade, Costin Raiu, Kurt Baumgartner
Sophisticated UEFI and BIOS attacks.
The Unified Extensible Firmware Interface (UEFI) is a software interface which serves as the intermediary between the firmware and the operating system on modern PCs. Established in 2005 by an alliance of leading software and hardware developers, Intel most notable amongst them, it’s now quickly superseding the legacy BIOS standard. This was achieved thanks to a number of advanced features that BIOS lacks: for example, the ability to install and run executables, networking and Internet capabilities, cryptography, CPU-independent architecture and drivers, etc. The very advanced capabilities that make UEFI such an attractive platform also open the way to new vulnerabilities that didn’t exist in the age of the more rigid BIOS. For example, the ability to run custom executable modules makes it possible to create malware that would be launched by UEFI directly before any anti-malware solution – or, indeed, the OS itself – had a chance to start. The fact that commercial-grade UEFI malware exists has been known since 2015, when the Hacking team UEFI modules were discovered. With that in mind, it is perhaps surprising that no significant UEFI malware has been found, a fact that we attribute to the difficulty in detecting these in a reliable way. We estimate that in 2018 we will see the discovery of more UEFI-based malware.[…]