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:

https://forums.puri.sm/t/user-flashable-coreboot-vs-chipsec-security-test-cases/1918

They also point out in that forum, and here:

https://puri.sm/posts/tpm-addon-for-librem-laptops/

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:

https://blog.invisiblethings.org/2015/12/23/state_harmful.html

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.

https://trmm.net/Installing_Heads
https://trustedcomputinggroup.org/
https://puri.sm/products/librem-15/

Purism Librem15 fails CHIPSEC security tests

Current Purism Librem15 systems — based on Intel x64/coreboot/SeaBIOS tech — results in 3 FAILs and 1 WARNING from CHIPSEC:

The UEFI Forum recommends that OEMs pass CHIPSEC’s tests before shipping units to customers. I wish modern BIOS-based OEMs would also heed that advice… The default install is to use an MBR-based partition, so also be wary of all of the existing BIOS-centric, MBR-based rootkits. Adhere all ‘evil maid’ warning signs with this laptop. If you have corporate policies that require NIST 800-147/155/193 requirements, you might have to work hard to justify this device. I wish it were not true: configurable or secure, choose one.

In other computer review news: the trackpad did not work during initial install, had to be rebooted. I’m guessing trackpad drivers aren’t integrated? You’ll have to use external mouse if you need to click on something during install of Linux. Same with backlit key and display intensity features: only worked after OS setup. Firmware security pedantry aside, nice hardware. Fan rarely kicks in, unlike some OEMs. It is nice to see a Mac-style trackpad instead of a PC-style touchpad with 2 explicit button areas, I’ve grown to dislike those. Startup and poweroff are both very fast. Reminds me of what a modern non-UEFI system should be like. Great, except we’re no longer in a world where security can be ignored. If you want an insecure BIOS box, you’ll probably enjoy this system. If you care about security, this is a BIOS box….

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

https://github.com/chipsec/chipsec/commits/master

https://github.com/chipsec/chipsec/releases/tag/v1.3.4

 

Embedi: UEFI BIOS holes. So much magic. Don’t come inside.

24 October, 2017
UEFI BIOS holes. So Much Magic. Don’t Come Inside.
In recent years, embedded software security has become a red-hot topic, attracting the attention of high profile security researchers from all around the globe. However, the quality of code is still far from perfect as long as its security is considered. For instance, the CVE-2017-5721 SMM Privilege Elevation vulnerability in the firmware could affect such scope of vendors like Acer, ASRock, ASUS, Dell, HP, GIGABYTE, Lenovo, MSI, Intel, and Fujitsu. This white paper is intended to describe how to detect a vulnerability in a motherboard firmware with the help of the following tools: Intel DAL, UEFITool, CHIPSEC, RWEverything, and how to bypass the patch that fixes this vulnerability.[…]

https://embedi.com/blog/uefi-bios-holes-so-much-magic-dont-come-inside

CHIPSEC 1.3.3 released

ErikBjorge released this 2 days ago:

New or Updated Modules:
* Added common.spi_access to verify the host processor access rights for different SPI regions

New or Updated Functionality:
* Added ability to search a memory region of a string
* Updated support for the RWE driver

Fixes:
* Added error handling if a register type is not supported

https://github.com/chipsec/chipsec/releases/tag/v1.3.3

https://github.com/chipsec/chipsec/commits/master

 

CHIPSEC adds RWEverything support on Windows

https://github.com/chipsec/chipsec/commit/60504da1bc06288ea632378f17e60a0d7df99471

“Use RWE/windows helpers when the corresponding driver is present.”

So, for any defending Windows systems, all of the CHIPSEC caution in WARNING.txt against the CHIPSEC HAL driver should also be applied to the RWEverything driver, “C:\Windows\System32\drivers\RwDrv.sys”.

https://github.com/chipsec/chipsec/blob/master/drivers/win7/readme

RWEverything license excerpt:

This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial or consumer products.

http://rweverything.com/

McAfee releases CHIPSEC 1.3.2

New or Updated Modules:
* Updated X64 Python for UEFI Shell

New or Updated Functionality:
* Updated FREG definitions
* Added mmap support to kernel module and chipsec device

Fixes:
* Fixed memory reads with kernel 4.8+
* Fixed version display in chipsec_util
* Fixed UEFI Shell X64 calling convention for SW SMI generation
* Fixed range check in bios_wp
* Fixed P2SB register accesses
* Fixed IOCTL_WRMMIO for x86_64 in Linux driver

Above relnotes aside, there are some other smaller features not listed above, in the changelog:
https://github.com/chipsec/chipsec/commits/master

I wish the CHIPSEC team signed their binary-only release of CPython 2.7x for UEFI, and/or included their build tree of the EDK2 that generates this, so we can build our own, hopefully ‘reproducably’.

I don’t see any ARM support[1]. Obviously, the title of below blog post was wrong, it was not released at Black Hat, AFAICT. Was this patch lost in Las Vegas? Is the ARM code a non-McAfee patch by Eclypsium that won’t be upstreamed into the GPL’ed CHIPSEC codebase? I wish I knew…

[1] https://firmwaresecurity.com/2017/07/25/chipsec-for-arm-to-be-released-at-black-hat/

PreOS Security releases CHIPSEC quickref for SysAdmins

[Disclaimer: I work for PreOS Security.]

CHIPSEC is a suite of dozens of tests/tools/utilities, many of which are strictly for security researchers. Timed with SysAdmin Appreciation Day, PreOS Security has created a 1-page quick reference for CHIPSEC for sysadmins. The below message also mentions an upcoming short ebook for sysadmins:

Currently this quickref is only availble by filling out a form:

https://preossec.com/free+ebook/

on the PreOS Security site, with some opt-in stuff to help the new startup.

PS: PreOS Security has joined the Twitosphere(sp), first post above. And we have a LinkedIn page. Please ‘Follow us’. Thanks!

https://twitter.com/PreOS_Security/
https://www.linkedin.com/company/preos-security

CHIPSEC for ARM: to be released at Black Hat

I nearly missed this CHIPSEC announcement in the below Black Hat abstract. Exciting.

Blue Pill for Your Phone
By Oleksandr Bazhaniuk & Yuriy Bulygin

In this research, we’ve explored attack surface of hypervisors and TrustZone monitor in modern ARM based phones, using Google Nexus 5X, Nexus 6P, and Pixel as primary targets. We will explain different attack scenarios using SMC and other interfaces, as well as interaction methods between TrustZone and hypervisor privilege levels. We will explore attack vectors which could allow malicious operating system (EL1) level to escalate privileges to hypervisor (EL2) level and potentially install virtualization rootkit in the hypervisor. We will also explore attack vectors through SMC and other low level interfaces, interactions between TrustZone and hypervisor (EL2) privilege levels. To help with further low level ARM security research, we will release ARM support for CHIPSEC framework and new modules to test issues in ARM based hypervisors and TrustZone implementations, including SMC fuzzer.

https://www.blackhat.com/us-17/briefings.html#blue-pill-for-your-phone

Intel releases LUV (Linux UEFI Validation) v2.1

Today Ricardo Neri of Intel announced the 2.1 release of LUV. In additon to updating Linux to v4.11, FWTS to V17.06.00, CHIPSEC to v1.3.1, BITS to v2079, and NDCTL v56, they also started doing nightly builds. Here are some of the other highlights of this release, from the announcement:

Gayatri Kammela won the prize of the most active contributor with many bug fixes and a new feature. She fixed our netboot image, which was missing the ramdisk(!). She added support for debugging and logging of BITS output via network. Likewise, she reworked the LUV configuration file to make more sense to both humans and computers by making clear when parameters are not used. She also investigated and fixed dependencies in systemd that caused delays in the execution of tests. Lastly, she fixed a couple of build-time bugs.

Naresh Bhat updated our Linux kernel recipe to retrieve the kernel configuration directly from the source tree rather than manually updating it. This helped us to remove those eyesore patches for updating our configuration that needed to be sent every time we bumped to a new kernel version. The overall result looks great and is closer to the intended use of the kernel and Yocto Projects’s scripts to merge multiple configuration fragments. I took this opportunity to sanitize the configuration for x86 to add missing configurations and reorganize them.

Sai Praneeth Prakhya added functionality to dump relevant and useful dumps as part of the testing results. Now LUV is capable of dumping the kernel’s boot log, the contents of the ACPI tables as well as the properties of the CPUs in the system. Very useful! Also, he helped us to bump to Linux v4.11. He also took burden of rebasing our implementation to detect firmware’s illegal memory access in this new version of Linux.

Matt Hart updated our GRUB configuration to automate boots across all CPU architectures by not waiting for human intervention to complete boots.

See the full announcement for lists of Known and Fixed Issues:
https://lists.01.org/mailman/listinfo/luv

In addition to stuff mentioned in LUV announcement, LUV also did some updates to how LUV calls CHIPSEC, see these posts:
https://lists.01.org/pipermail/chipsec/2017-July/thread.html

These days, LUV-live ships with BIOS MBR or UEFI GPT partition types, local or network boot types, and x86 or x64 architecture type, multiple choices for the image:
https://download.01.org/linux-uefi-validation/v2.1/
https://download.01.org/linux-uefi-validation/v2.1/sha256sums.asc

 

CHIPSEC in BlackArch Linux

It has been in there for a while, but I don’t think I’ve seen an announcement.

https://github.com/BlackArch/blackarch/issues/1568
https://github.com/BlackArch/blackarch/tree/master/packages/chipsec
https://www.blackarch.org/tools.html
https://www.blackarch.org/hardware.html
https://www.blackarch.org/downloads.html

So you can use LUV-live to use CHIPSEC in a batch mode, or you can use BlackArch live to use CHIPSEC in an interactive mode.

PS: Kali status:
https://bugs.kali.org/view.php?id=3940
https://github.com/chipsec/chipsec/wiki/Using-CHIPSEC-with-Kali-Linux

some recent CHIPSEC presentations

I’m not sure that I’ve pointed to all of the recent CHIPSEC presentations that’ve happened recently. I don’t know that I have a complete list. 😦 Here are two recent ones, maybe some more in below tweets.

Attacking hypervisors through hardware emulation
https://www.troopers.de/downloads/troopers17/TR17_Attacking_hypervisor_through_hardwear_emulation.pdf

Exploring your system deeper
https://github.com/comaeio/OPCDE/blob/master/Exploring_Your_System_Deeper/opcde_ExploringYourSystemDeeper_updated.pdf
http://www.c7zero.info/stuff/csw2017_ExploringYourSystemDeeper_updated.pdf

—–begin slideshare.net stuff—–

—–end slideshare.net stuff—–

CHIPSEC whitelist gets updated

https://github.com/advanced-threat-research/efi-whitelist

CHIPSEC_GUI

There’s a relatively new GUI front-end to the command line-based CHIPSEC project, called CHISPEC_GUI. This GUI for chipsec 1.2.5 provides a fairly simple design but lets you select each module that you want to run. It is made with PyQt4. It is getting updated to Chipsec 1.3.0 with the appropriate module additions written into the GUI. It was originally written in Persian by Emad Helmi, and translated to English by Alex Floyd of PreOS-Security.

English version:
https://www.github.com/mex20/chipsec_gui

Forked from Persian version:
https://www.github.com/EmadHelmi/chipsec_gui

CHIPSEC 1.3.0 released

New/updated modules:
* tools.uefi.whitelist – The module can generate a list of EFI executables from (U)EFI firmware file or extracted from flash ROM, and then later check firmware image in flash ROM or file against this list of [expected/whitelisted] executables
* tools.uefi.blacklist – Improved search of blacklisted EFI binaries, added exclusion rules, enhanced blacklist.json config file
* tools.smm.rogue_mmio_bar – Experimental module that may help checking SMM firmware for MMIO BAR hijacking vulnerabilities described in “BARing the System: New vulnerabilities in Coreboot & UEFI based systems” (http://www.intelsecurity.com/advanced-threat-research/content/data/REConBrussels2017_BARing_the_system.pdf) by Intel Advanced Threat Research team at RECon Brussels 2017
* tools.uefi.uefivar_fuzz – The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size.

New/updated functionality:
* Debian packaging support
* Compiling in setup.py and automated loading of chipsec.kext kernel module on macOS
* Internal Graphics Device support including software DMA via Graphics Aperture
* Improved parsing andsearch within UEFI images including update capsules
* Export of extracted EFI firmware tree in JSON format
* Export of CHIPSEC results in JSON format via –json command-line argument
* EFI (de-)compression ported from uefi-firmware-parser project
* Decompression to macOS helper to parse Mac EFI firmware images
* Support of command-line arguments in chipsec_util.py
* SMI count command
* Improved platform dependent Flash descriptor parsing
* ReadWriteEverything helper to work with RWE driver
* map_io_space to improve SPI read performance on Linux
* Native (OS based) access PCI, port I/O and CPU MSR to Linux helper
* Improved chipsec_util.py unit testing

See full announcement for list of bugfixes.

https://github.com/chipsec/chipsec/releases/tag/v1.3.0