Steven Ellis: firmware updating on Linux

Steven Ellis of Red Hat has a new article on OpenSource.com on updating firmware and UEFI, with lots of good stuff to read. He mentions his next article will be on the topic of patching SSD firmware, which sounds very interesting. Spoiler alert: I’m exerpting his Recommendations from the end of the post:

[…] In this article, I’ll walk through my recent firmware update on Linux, and I’ll share a few recommendations based on that experience. […]
Recommendations:
* More vendors should allow UEFI BIOS updates directly from the BIOS-style interface. UEFI shell command-line isn’t for the casual user.
* If your vendor supplies a bootable image, try to use that first.
* Investigate what supported tools are available, but consider using a live image for patching. I’m somewhat wary of tools that build and install their own kernel modules.
* Assist projects—like flashrom—to avoid these issues in the future.
[…]

https://opensource.com/life/16/8/almost-open-bios-and-firmware-update-tips-linux-users

Using Radare to emulate BIOS

(There’s a Twitter URL for it, but I’ve lost it, sorry.)
Emulating a simple bootloader

Generally speaking, emulating a bootloader is simpler than it is for regular binaries, because they lack external libraries and usually have direct access to memory and hardware. In this case, the bootloader is a binary for x86 architecture which runs in 16-bits real mode using BIOS calls to perform its loading duties and textual input/output. The idea here is to emulate Cropta1 crackme using radare2 ESIL emulation, providing the needed BIOS via a trivial quick & dirty python implementation of just what it’s needed to run the crackme code. There are several ways to do it, I tried two of them and here is the story. […]

http://radare.today/posts/emulating-simple-bootloader/

 

Multiple Intel systems have SMM runtime EoP

See the full announcement for the list of vulnerable products. Regardless of model, it sounds like no fix until early September.

SmmRuntime Escalation of Privilege
Intel ID:      INTEL-SA-00056
Product family:      Intel® Server Board S1200/1400/1600/2400/2600/4600 series
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important
Original release:      Aug 08, 2016

Intel is releasing mitigations for a privilege escalation issue. This issue affects the UEFI BIOS of select Intel Products. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable function to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Other vendors’ products which use the common BIOS function SmmRuntime may be impacted.  To find out whether a product you have may be vulnerable to this issue, please contact your system supplier. Intel highly recommends applying the mitigations. For Intel branded products where a mitigation is still pending, we recommend following good security practices including running with least privilege and keeping security software and operating systems up to date. […]

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00056&languageid=en-fr

PCWelt: UEFI tricks for PCs

Here’s an interesting article for end users, with a handful of tool pointers I haven’t seen before:

http://www.pcwelt.de/ratgeber/BIOS_2.0__10_UEFI-Tricks_fuer_Insider-PC_und_Mainboards-8723414.html

English translation:

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.pcwelt.de%2Fratgeber%2FBIOS_2.0__10_UEFI-Tricks_fuer_Insider-PC_und_Mainboards-8723414.html&edit-text=

Rootkits and Bootkits: new chapter available

An update on this book, the early-access ebook edition has a new chapter on UEFI BIOS vulnerablities — and NoStarch has a 30% off earlybird discount:

No Starch Press: Rootkits and Bootkits

https://www.nostarch.com/rootkits

SeaBIOS TPM support improved

Stefan Berger of IBM submitted a 6-part patch to the SeaBIOS project, updating it’s TPM support, his patch comment follows:

This series of patches extends the TPM2 code to extend the BIOS related PCRs 0-7 in all available banks. This prevents that these PCRs remain untouched and filled with bogus values by applications. For example, the SHA1 hash is extended into the SHA256 bank. The value that is extended into this bank is essentially a SHA1 with zero bytes used for filling it to the size of a sha256 hash. This is done for all PCR banks of the TPM2 where these PCRs are available. In v2 of this series I also extended the log functions for logging the additional hashes. So there are more patches now.

For more information, see the full patch sent to the SeaBIOS list:
https://www.coreboot.org/mailman/listinfo/seabios

TCG updated multiple specs

The Trusted Computing Group (TCG) has released revisions to multiple specifications:
I wish I knew why WordPress inserts the additional whitespace in these posts…. 😦

PC Client Specific Platform Firmware Profile Specification, Family 2.0, Level 00 Revision 00.21 and Errata
The PC Client Platform Specific Profile for TPM 2.0 systems defines the requirements for platform firmware to initialize and interact with a TPM 2.0 device in a PC Client platform.  This specification should be used in conjunction with the TCG UEFI Protocol Specification Family 2.0, the TCG Physical Presence Interface Specification, and the TCG ACPI Specification to design and implement a PC Client TPM 2.0-enabled platform.  This specification replaces the requirements defined in the PC Client Implementation Specification for Conventional BIOS and the PC Client UEFI Platform Specification for systems with TPM 2.0 devices.
http://www.trustedcomputinggroup.org/pc-client-specific-platform-firmware-profile-specification/

PC Client Work Group EFI Protocol Specification, Family 2.0, Level 00, Revision 00.13
The purpose of this document is to define a standard interface to the TPM on an UEFI platform. It defines data structures and APIs that allow an OS to interact with UEFI firmware to query information important in an early OS boot stage. Such information include: is a TPM present, which PCR banks are active, change active PCR banks, obtain the TCG boot log, extend hashes to PCRs, and append events to the TCG boot log.The latest revision of this specification is written with platforms with TPM 2.0 devices in mind, but nothing in this specification prevents the use with platforms with TPM 1.2 devices.
http://www.trustedcomputinggroup.org/tcg-efi-protocol-specification/

TCG Storage Opal Test Cases Specification, Version 2.00 Errata Version 1.00, Revision 1.00
The Opal Test Cases Specification contains a set of tests that are intended to verify the correct behavior of a storage device implementing the Opal SSC Specification. These test cases are intended to be used as a basis for the compliance component of the projected Storage certification program, which would seek to ensure a high level of interoperability of storage devices from multiple vendors.
http://www.trustedcomputinggroup.org/tcg-storage-opal-test-cases/

Multiple Stakeholder Model , Revision 3.40
The Multiple Stakeholder Model (MSM) is an informative reference document that describes use cases, recommended capabilities, and various implementation alternatives to allow multiple stakeholders to coexist safely on a mobile platform.  This document includes guidance on how to leverage TCG specifications to realize each alternative.  In particular, this document emphasizes the role of the Trusted Platform Module (TPM), the Mobile Common Profile, and the Mobile Reference Architecture specifications to support these capabilities for multiple stakeholders.  The goal of the MSM is to provide trusted services, for example, TPM and Trusted Network Communications (TNC), in a secure and efficient manner to all interested stakeholders (both local and remote) for a given mobile device. This guidance is applicable to all mobile devices (smartphones, feature phones, basic phones, etc.) and may be useful for other computing devices.  The target audience for this document includes designers, manufacturers, system integrators, application developers, and implementers of Trusted Computing technologies in mobile platforms.
http://www.trustedcomputinggroup.org/multiple-stakeholder-model/
http://www.trustedcomputinggroup.org/tpm-library-specification/
http://www.trustedcomputinggroup.org/tcg-tpm-2-0-mobile-common-profile/
http://www.trustedcomputinggroup.org/tpm-2-0-mobile-reference-architecture-specification/

TNC IF-M Segmentation Specification Version 1.0, Revision 5
The Trusted Network Communications (TNC) Work Group defines an open solution architecture that enables network operators to evaluate and enforce policies regarding endpoint integrity when granting access to a network infrastructure. As TCG’s Trusted Network Communications (TNC)-enabled technology is deployed in real-world environments, we’re learning that deplorer’s have the need to collect robust posture information to support endpoint compliance, security automation, and continuous monitoring. IF-M is the communication layer of the TNC architecture used to connect the endpoint components that collect information about the endpoint, and the corresponding components on a policy server that receive that information and act on it. IF-M is designed to be flexible to support communication of virtually any type of information about the endpoint that the enterprise might wish to know.

TCG Updates IF-M Segmentation to Enable Efficient Information Exchange


http://www.trustedcomputinggroup.org/tnc-ifm-segmentation-specification/

Trusted Network Communications (TNC)

Intel ACPI IGD OpRegion Spec, and IntelSiliconPkg added to Tianocore

Jiewen Yao of Intel added a new module to the public Tianocore source project.

[PATCH 1/2] IntelSiliconPkg: Add initial version.
This package will include open source common Intel silicon related modules.
This series patch adds the initial version of IntelSiliconPkg and an include file.
We will use IntelSiliconPkg for open source common Intel silicon related modules.

I hope Intel transitions some of it’s binary-only releases from it’s Intel Firmware Support Package (FSP) into this source-only-based package!

It appears the first candidate for this new IntelSiliconPkg is the Intel IGD (Integrated Graphics Device).

[PATCH 2/2] IntelSiliconPkg/IgdOpRegion: Add definition for Intel IGD OpRegion.
IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
Add IGD OpRegion definition from Intel Integrated Graphics Device OpRegion Specification.

OpRegion structures: Sub-structures define the different parts of the OpRegion followed by the main structure representing the entire OpRegion. Sub-structures:
INTEL_IGD_OPREGION_MBOX1  MBox1; // Mailbox 1: Public ACPI Methods
INTEL_IGD_OPREGION_MBOX2  MBox2; // Mailbox 2: Software SCI Inteface
INTEL_IGD_OPREGION_MBOX3  MBox3; // Mailbox 3: BIOS/Driver Communication
INTEL_IGD_OPREGION_VBT    VBT;   // Video BIOS Table (OEM customizable data)

Click to access acpi_igd_opregion_spec_0.pdf

Hmm, I don’t see IGD mentioned in the list of ACPI specs:
http://uefi.org/acpi

I am pretty sure that one of Intel’s Beyond BIOS whitepapers mentions IGD/ACPI/UEFI interactions, sorry I forget which one it is, it may have been the one on BIOS memory maps:
https://firmware.intel.com/share

It appears Intel first released this spec in 2008. Besides UEFI, Intel IGD OpRegion support is in coreboot as well. And in the Linux kernel.
https://lwn.net/Articles/301879/
https://lwn.net/Articles/292839/
https://lwn.net/Articles/429319/

For more information, see the patch on the EDK2-devel list:
https://lists.01.org/mailman/listinfo/edk2-devel

SuSE adds BIOS/UEFI to their certification bulletins

Drew of SuSE has a new blog post clarifying UEFI -vs- BIOS:

SuSE even has a certification program, as this blog mentions:

“[…] All YES CERTIFICATION bulletins list how the hardware and operating system were configured and tested during certification. On a bulletin, under the tested configuration section there is a BIOS/UEFI line, it will list either UEFI, BIOS or UEFI-Legacy. This indicates how the system was configured and tested. It then lists the version and date of the system firmware installed on the hardware. […]”

This certification program doesn’t cover [implementation differences in] UEFI Secure Boot. While the current change in their certification — to clarify if system has a UEFI class 1-3 firmware — is nice, what would be USEFUL would be to list CHIPSEC version and a list a list of which security modules it fails. And the results of FWTS’s tests (does Canonical’s FWTS build on SuSE?). When a system is tested, I’d like to see the test results, please. And does this mean that SuSE will not ship any coreboot- or U-Boot-based systems, but always UEFI/BIOS-based ones? Given how crucial firmware is to a system, I am amazed at how little consumers care about this information. I guess I should be happy SuSE is giving 1-line of data to firmware. I’d like a paragraph.

 

https://www.suse.com/communities/blog/comparison-uefi-bios-operating-system-perspective/

BIOS mod lab at upcoming SecuringHardware.com training

For those who need Evil Maid skills take note: Joe Fitzpatrick has added a BIOS mod lab to his Black Hat training on x86 physical attacks.

Applied Physical Attacks on x86 Systems
Joe FitzPatrick, SecuringHardware.com
July 30-August 2

This course introduces and explores attacks on several different relatively accessible interfaces on x86 systems. Attendees will get hands-on experience implementing and deploying a number of low-cost hardware devices to enable access, privilege, and deception which is in some cases imperceptible from software. The course has several modules: USB, SPI/BIOS, I2C/SMBus, PCIe, and JTAG. Each begins with an architectural overview of an interface, and follows with a series of labs for hands-on practice understanding, observing, interacting with, and exploiting the interface, finishing with either potentially exploitable crashes or directly to root shells.

https://www.blackhat.com/us-16/training/applied-physical-attacks-on-x86-systems.html

Plutomaniac’s ME Analyzer

There are three tools from the win-raid.com firmware modding community that I’ve not used, but I’ve heard are quite awesome tools. The first is UBU[1], the second is GOPupd[2], and the third is ME Analyzer, the subject of this blog post. ME Analyzer is a tool by Plutomaniac, a member of the win-raid.com firmware modding community. The tool parses Intel BIOS images and provides various infos about Management Engine Firmware in them. It also has a related Firmware Database which contains a lot of interesting information.

ME Analyzer is an Intel Engine Firmware Analysis Tool, a tool that you can show various details about Intel Engine Firmware (Management Engine, Trusted Execution Engine, Service Platform Services) images. It can be used to identify whether the firmware is updated, what Release, Type, SKU it is etc. Features:
* Supports all current & legacy Engine firmware (ME 1.x – 11.x , TXE 1.x – 2.x & SPS 1 – 4)
* All types of firmware files are supported (ME/TXE/SPS Regions, BIOS images etc)
* Partial Firmware Update support for Corporate ME 8-11 enabled platforms
* UEFI Bios Updater (UBU) and Lordkag’s Extractor integration support
* Firmware Family (ME, TXE or SPS), Date & Version number detection
* Production, Pre-Production & ROM-Bypass firmware release detection
* Region (Stock or Extracted) & Update firmware type detection
* Identification of the platform that the firmware was configured for via FITC
* SKU & target platform detection for all supported firmware releases
* Security Version Number (SVN), Version Control Number (VCN) & PV-bit detection
* Intel SPI Flash Descriptor Access Region detection, Skylake compatible
* Identification of whether the imported Engine firmware is up-to-date
* Proper CPT/PBG SKU & BlackList Table detection for ME 7.x firmware
* Special Apple Macintosh ME 7.0 & 9.5 firmware SKU support
* FWUpdate OEMID detection at Region & SPI/BIOS images
* Multiple drag & drop & sorting of rare/problematic Engine Firmware
* Multiple Engine Firmware Region detection, number only
* Unidentifiable Engine Firmware Region (ex: Corrupted, Compressed) detection
* Reports unknown firmware not found at the Engine Repository Database
* Reports unknown firmware Major, Minor, SKU, Type etc releases
* Shows colored text to signify the importance of notes, warnings, errors etc

Engine Firmware Repository Database:

ME Analyzer’s main goal is to allow users to quickly determine & report new firmware versions without the use of special Intel tools (FIT/FITC, FWUpdate) or Hex Editors. To do that effectively, a database had to be built. The Intel Engine Firmware Repositories is a collection of every ME, TXE & SPS firmware I have found. It’s existence is very important for ME Analyzer as it allows me to find new types of firmware, compare same major version releases for similarities, check for updated firmware etc. Bundled with ME Analyzer there’s a file called MEA.dat which is required for the program to run. It includes all CSE firmware that are available at the Repository thread. This accommodates two actions: a) Check whether the imported firmware is up to date and b) Help find new CSE firmware releases sooner by reporting them at the Intel Management Engine: Drivers, Firmware & System Tools or Intel Trusted Execution Engine: Drivers, Firmware & System Tools threads respectively.

ME Analyzer is closed source freeware, targetting Microsoft Windows platform. As always, if you can’t review the code, be cautious where/how you use it, until you are ready to ‘trust’ the author.

ME Analyzer requires ME Util v0.1, and includes a modified version of it:
https://github.com/skochinsky/me-tools

More information:
http://www.win-raid.com/t840f39-ME-Analyzer-Intel-Engine-Firmware-Analysis-Tool.html
http://www.win-raid.com/t832f39-Intel-Management-amp-Trusted-Execution-Engine-Firmware-Repository.html
http://www.win-raid.com/t596f39-Intel-Management-Engine-Drivers-Firmware-amp-System-Tools.html
http://www.win-raid.com/t624f39-Intel-Trusted-Execution-Engine-Drivers-Firmware-amp-System-Tools.html

[1]

UBU 1.43 released

Tool review: UBU-helpers


[2]

tool: GOPupd

BIOS analysis presentation at Analyze 2016

Analyze 2016 takes place in March in San Francisco. It is a “Security community event for malware and exploit analysis research”. Amongst the presentations is one on BIOS analysis by two of the Intel Advanced Threat Research (ATR) team!

Talks:
Tom Bennett – Whose RAT Is It Anyways?
Aaron Shelmire – Sections, Segments, and Functions, oh my! Hashing your way to analytical shortcuts.
Edward Miles – Making sense of ProGuard’s mess
Oleksandr Bazhaniuk/Yuriy Bulygin – Different methods of BIOS analysis: Static, Dynamic and Symbolic execution
Darren Spruell – Malicious Traffic Distribution: Tactics and Response
Rick Wesson – Static Malware Analysis on GPUs
Chip McSweeney – DGA Antivenom: Stopping new configurations before analysis
Jing Xie – Risks of iOS Remote Hot-Patching
Alexander Matrosov – Distributing the reconstruction of IR for large scale malware analysis
http://www.analyze.cc/Waylon Grange – Wherefore by their crypto ye shall know them
Armin Buescher – Sanzoku APT

http://www.analyze.cc/

CHIPSEC training at TROOPERS

The Intel CHIPSEC team doesn’t get out much to give training to the public often, so this upcoming 2-day of CHIPSEC training at TROOPERS is nice!

Security below the OS with CHIPSEC framework
Oleksandr Bazhaniuk, Yuriy Bulygin

A variety of attacks targeting platform firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, UEFI secure boot and OS loaders. This workshop provides a hands-on opportunity to learn how to use an open source CHIPSEC framework https://github.com/chipsec/chipsec to test systems for vulnerabilities in low-level platform firmware components, problems with firmware security protections as well as develop your own modules in CHIPSEC which test for known issues or implement tools identifying new issues. Agenda:

* Introduction to platform hardware and access with CHIPSEC
* Introduction to platform firmware such as BIOS, UEFI firmware, SMI handlers
* Overview of main components of CHIPSEC framework
* Analyzing main firmware components and configuration
* Assessing systems for vulnerabilities in the BIOS and other firmware
* Developing vulnerability testing modules
* Developing fuzzers for firmware interfaces and other security tools
* BIOS forensics with CHIPSEC

https://www.troopers.de/events/troopers16/567_security_below_the_os_with_chipsec_framework/

BITS 2073 released

Burt Triplett has announced the release of BITS (BIOS Implementation Test Suite) version 2073:

– efi: Support EFI_IP4_CONFIG2_PROTOCOL and associated data structures

– _socket: Use EFI_IP4_CONFIG2_PROTOCOL if available, falling back to EFI_IP4_CONFIG_PROTOCOL

 BIOSes based on current versions of EDK2, including current OVMF, only support EFI_IP4_CONFIG2_PROTOCOL, and drop support for EFI_IP4_CONFIG_PROTOCOL.  Support configuring IPv4 via the newer protocol, falling back to the older protocol for compatibility with existing BIOSes.

  In either case, reuse the existing IPv4 configuration if present, and only kick off DHCP if not already configured.  This also allows systems that require manual IPv4 configuration to perform such configuration (via the EFI shell, the BITS Python interpreter, or any other means) and subsequently use that configuration with BITS.

More info:
http://biosbits.org/downloads/bits-2073.zip
https://github.com/biosbits/bits/ (tag bits-2073)
https://lists.01.org/pipermail/bits/2016-January/000001.html

BIOS maker: WinZent Technologies AB

WinZent Technologies AB is headquartered in Stockholm, Sweden. They make a BIOS and an operating system for 32-bit Intel systems. According to their LinkedIn page, they were founded in 2013 and have 11-50 employees. Their OS is called “wIOS” (WinZent Instant OS). Their BIOS is called “wION” (WinZent Instant ON BIOS) — the B for BIOS is silent :-). Their code is written in assembler, not C, and is focused on performance and size. The binary image of their BIOS is apparently less than 64KB. Their OS is 116KB, targets 32-bit systems, and has FAT32 support.

Some fun quotes from a 2014 embedded presentation WinZent gave:
“UEFI very complex and bloated.”
“coreboot is basically Linux.”
“Linux is complex and bloated.”

They have a video of their BIOS loading in 1second, with an AMI BIOS taking about 8 seconds.
http://winzenttech.com/AdlinkwIONvsAMI.html

“WinZent’s software has a footprint small enough to execute in the cache memory which is 1500 times faster than the DRAM memory extensively used by other BIOS and general purpose OS, such as Linux, OSX and Windows.”

If you have a MinnowBoard MAX — or a Terasic DE2i-150 — you can get a BIOS from them to try out.

The BIOS uses ACPI version 2. ACPI version 6.1 was released last week.

Their BIOS does NOT use Intel FSP. I don’t have the URL or quote handy, but on the Minnowboard or eLinux list in the past, someone from WinZent mentioned this.

The BIOS targets Intel x86 systems, specifically “ATOM, Silverthorn, Diamondville, Cedarview, Pineview, Lincroft, and CloverTrail.”. Unclear about the newer Intel 32-bit boards systems.

They claim their BIOS works with “all operating systems”, which is too vague to be useful. They mention Microsoft Windows 7-10, Linux, and Android.

I see no references to any security features. If speed and size are your only concerns, WinZent sounds excellent. If you have security concerns, then you might consider something else.

There are multiple PDFs to read more about their technology:
http://winzenttech.com/Tech.html
http://winzenttech.com/wION.html
http://winzenttech.com/wIOS.html

Click to access wION%20Tech%20Spec.pdf

http://winzenttech.com/Media.html
https://www.linkedin.com/company/winzent-technologies-ab

WinZent releases wION BIOS for Minnow