Vincent: Ghosts of GUID’s past

Vincent has a new blog post, with some history of UEFI and recent security conference interactions, and includes a snippet of some old EFI code from Ken Reneris!

(I used to work with Ken. He is amazingly proficient coder. When he went on vacation to get married, we replaced his keyboard driver such that the ‘;’ key would replace the ‘:’ key randomly. (Back then drivers weren’t signed and a lot easier to replace.) His response was to rewire the person’s mouse so that it would work upside down/backwards.)

http://vzimmer.blogspot.com/2018/10/ghosts-of.html

Vincent to keynote Open Source Firmware Conference

Vincent has a new blog post out, with lots of photos of legacy (pre-UEFI) hardware, and various news items, such as:

[…]Following on the spirit of openness, I was honored to be invited to keynote the upcoming open source firmware summit https://osfc.io/. The landing page for my talk will be https://osfc.io/talks/keynote. This should follow the arc on reducing friction and providing transparency for host firmware development.[…]

http://vzimmer.blogspot.com/2018/06/system-firmware-past-present-future.html

UEFI security presentation at Seattle DC206 Meeting

If you missed the Intel presentation from BlackHat Briefings this summer, and if you are in the Seattle area this Sunday, Vincent Zimmer of Intel will be reprising this presentation at the DC206 Meeting at the Black Lodge Research hackerspace.

https://www.dc206.org/?p=216

What: Oct DC206 Meeting: Firmware is the New Black
When: October 15th, 1-3pm
Who: Vincent Zimmer
Where: Black Lodge Research

Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities

In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).

https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities
http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html
https://github.com/rrbranco/BlackHat2017/blob/master/BlackHat2017-BlackBIOS-v0.13-Published.pdf

https://blacklodgeresearch.org/

https://www.facebook.com/events/1611758852222280/

Intel’s Black Hat UEFI presentation online

Vincent has a new blog post about the recent talk about UEFI security that Intel just gave at Black Hat Briefings.

http://vzimmer.blogspot.com/2017/08/black-hat-usa-2017-firmware-is-new-black.html

https://www.blackhat.com/us-17/briefings.html#firmware-is-the-new-black-analyzing-past-three-years-of-bios-uefi-security-vulnerabilities

https://github.com/rrbranco/BlackHat2017

https://github.com/rrbranco/BlackHat2017/blob/master/BlackHat2017-BlackBIOS-v0.13-Published.pdf

https://www.darkreading.com/vulnerabilities—threats/7-hardware-and-firmware-hacks-highlighted-at-black-hat-2017/d/d-id/1329442

Black Hat Briefings: Firmware is the New Black

 

Firmware is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities
Bruce Monroe, Rodrigo Branco, Vincent Zimmer

In recent years, we witnessed the rise of firmware-related vulnerabilities, likely a direct result of increasing adoption of exploit mitigations in major/widespread operating systems – including for mobile phones. Pairing that with the recent (and not so recent) leaks of government offensive capabilities abusing supply chains and using physical possession to persist on compromised systems, it is clear that firmware is the new black in security. This research looks into BIOS/UEFI platform firmware, trying to help making sense of the threat. We present a threat model, discuss new mitigations that could have prevented the issues and offer a categorization of bug classes that hopefully will help focusing investments in protecting systems (and finding new vulnerabilities). Our data set comprises of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past 3 years and the analysis was manually performed, using white-box and counting with feedback from various BIOS developers within the company (and security researchers externally that reported some of the issues – most of the issues were found by internal teams, but PSIRT is involved since they were found to also affect released products).

https://www.blackhat.com/us-17/briefings/schedule/index.html#firmware-is-the-new-black—analyzing-past-three-years-of-biosuefi-security-vulnerabilities-6924

 

NIST SP 800-193: Platform Firmware Resiliency Guidelines

I thought I got all the appropriate NIST announcements, but missed this, found it in Vincent’s recent blog post:

http://vzimmer.blogspot.com/2017/05/uefi-and-security-postings.html

Very exciting to see this NIST document!

Draft NIST Special Publication 800-193
Platform Firmware Resiliency Guidelines
Andrew Regenscheid

This document provides technical guidelines and recommendations supporting resiliency of platform firmware and data against potentially destructive attacks. The platform is a collection of fundamental hardware and firmware components needed to boot and operate a system. A successful attack on platform firmware could render a system inoperable, perhaps permanently or requiring reprogramming by the original manufacturer, resulting in significant disruptions to users. The technical guidelines in this document promote resiliency in the platform by describing security mechanisms for protecting the platform against unauthorized changes, detecting unauthorized changes that occur, and recovery from attacks rapidly and securely. Implementers, including Original Equipment Manufacturers (OEMs) and component/device suppliers, can use these guidelines to build stronger security mechanisms into platforms. System administrators, security professionals, and users can use this document to guide procurement strategies and priorities for future systems.

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-193

 

new editions of Beyond BIOS and Harnessing the UEFI Shell

Intel Press published the first and second editions of these two books a few years ago, but it appears Degruyter is publishing revised third editions!

Harnessing the UEFI Shell: Moving the Platform Beyond DOS, Third Edition
Rothman, Michael / Zimmer, Vincent / Lewis, Tim
https://www.degruyter.com/view/product/484477

Beyond BIOS: Developing with the Unified Extensible Firmware Interface, Third Edition
Zimmer, Vincent / Marisetty, Suresh / Rothman, Michael
https://www.degruyter.com/view/product/484468

 

New Intel/UEFI whitepaper: Establishing the Root of Trust

https://twitter.com/Intel_UEFI/status/773597835467956224

http://www.uefi.org/sites/default/files/resources/UEFI%20RoT%20white%20paper_Final%208%208%2016%20%28003%29.pdf

Vincent Zimmer and Michael Krau of Intel have written a new whitepaper for the UEFI Forum: “Establishing the root of trust”.

The first step in securing a computing device – from a simple embedded device to a supercomputer and everything in between – is to ensure that it can start up under the following conditions:
– It is operating as expected
– All the firmware needed to run the system is intact
– It has not been tampered with in any way

As described in the first white paper in this series, Understanding the Chain of Trust and Its Vital Role in Keeping Computing Systems Secure, the UEFI specification includes a mechanism for ensuring the integrity and security of firmware (the all-important link between the hardware and the operating system) as a system starts up. This mechanism is called Secure Boot and uses public key cryptography to validate that each piece of firmware has been digitally signed and is therefore unmodified as the system starts up. In a chain of trust, each piece of firmware must be digitally signed before it can start up. Once one piece of code has been validated, it can then validate the next section and so on until the system is fully booted and control handed over to the operating system. But how does that chain get started? While difficult, it would be possible for an attacker to inject malicious attack code of some sort prior to start of the chain of trust to gain low-level and nearly undetectable control over the system. To prevent this, the chain of trust requires a strong foundation. In modern systems, this is known as the root of trust. A root of trust, one that can be counted on to anchor the chain of trust in the face of the most determined attackers, can be established in a number of ways. The most secure approaches use some form of an unchangeable section of hardware to validate the initial keyed signature, but there are a number of effective approaches. Ultimately it comes down to the level of security you’re comfortable with and an understanding of the approach used to establish the root of trust. This white paper looks at several common methods for establishing a root of trust as the basis for the UEFI Secure Boot process. […]

new UEFI Forum docs on HTTPS Boot and EDK2 profiling

https://twitter.com/Intel_UEFI/status/751451638716469249

https://github.com/tianocore-docs/Docs/raw/master/White_Papers/EDKIIHttps_TLS_BootGettingStartedGuide_07.pdf

https://github.com/tianocore-docs/Docs/raw/master/White_Papers/A_Tour_Beyond_BIOS_Implementing_Profiling_in_EDK_II.pdf

A Tour Beyond BIOS Implementing Profiling in EDK II
Jiewen Yao, Vincent Zimmer, Star Zeng, Fan Jeff
The Unified Extensible Firmware Interface (UEFI) and Platform Initialization (PI) specification defines rich execution environments such as Security (SEC), Pre-EFI Initialization (PEI), Driver Execution Environment (DXE), System Management Mode (SMM) and UEFI Runtime (RT) for firmware drivers. There are more and more features added into a firmware. At same time, the firmware still has a resource constrained environment. In addition to functionality, the size, performance, and security are three major concerns of a firmware engineer. This paper introduces several profiling features implemented in EDK II to help the UEFI firmware developer to analyze the size, performance and security of a UEFI firmware implementation.

Getting Started with UEFI HTTP over TLS (HTTPS) Boot on EDK II
Wu Jiaxin
HTTP over TLS (HTTPS) boot is a standard implementation for securely booting using the Unified Extensible Firmware Interface (UEFI) over a network device. HTTPS Boot is especially important for clients using potentially insecure networks outside of corporate infrastructure. Security for UEFI HTTPS Boot is provided by the underlying Transport Layer Security (TLS).
This document assumes that the reader is familiar with the EDK II HTTP Boot Getting Started Guide.