New FWTS Discuss Mailing List Created

FWTS is the FirmWare TestSuite for Linux from Canonical. The project has had an Announce and a Develop mailing list; they’ve just created a Discuss list. This will be useful for enterprise users and security researchers who use these tools.

A new fwts-discuss@lists.ubuntu.com has been created for general Firmware Test Suite related discussions. Email from other related firmware projects may be cross-posted to this as long as they are vaguely related to fwts.
More information:

https://lists.ubuntu.com/mailman/listinfo/fwts-discuss
https://lists.ubuntu.com/archives/fwts-devel/2015-May/006103.html

Skyport Systems continuously verify firmware

Multiple news sites are carrying stories about a new security startup, Skyport Systems and their new cloud solution. From the perspective of firmware, their server is supposed have it’s firmware ‘continuously verified’:

The SkySecure Server is a trusted computing platform. It consists of purpose-engineered hardware that is extremely difficult to compromise and can be deployed in untrusted environments. Some of the features include:
 * A hardware-based root-of-trust for the entire system lifecycle from the point of manufacture onwards
 * Continuous verification of the hardware, firmware, BIOS, OS, and workloads
 * Compartmentalization of subsystems – I/O, x86 compute, workloads, compartments – which isolates vulnerability in the event of a breach
 * Tamper-resistant hardware

I have no personal experience with their platform, nor what kind of BIOS they’re using, and how they’re verifying it. It appears to be closed-source, I’ve not been able to find any code. Speak up if you find the code!

More information;
http://www.eweek.com/servers/skyport-emerges-from-stealth-intros-skysecure-servers.html
http://www.crn.com/news/security/300076844/skyport-systems-emerges-from-stealth-with-hyper-secure-converged-server.htm
https://www.skyportsystems.net/solution/

LegbaCore releases new firmware research at RSA Conference

LegbaCore gave a firmware security talk at last month’s RSA Security Conference. The presentation materials and some video, are online.

LegbaCore, along with Invisible Things Lab are IMO the top two firmware security firmws, so when they release substantial new research like this, everyone should pay attention.

(If you attended my LinuxFestNorthWest talk last month on firmware security tools, the advise the LegbaCore covers in this presentation is much more detailed than what I covered.)

This is probably the best advise available to date for enterprises to protect themselves from bootkits. More up-to-date than the NIST SP guidelines or any other best practices that I know of. Everyone involved with protecting enterprise systems needs to study this carefully.

Title: Are You Giving Firmware Attackers a Free Pass?
Synopsis: Yes. Yes you are. Because you’re not patching away the vulnerabilities we and others have found and disclosed, and you’re not inspecting whether anyone has infected your firmware. This talk provides an introduction to firmware threats & capabilities. But because it is longer than previous talks like “Betting BIOS Bugs Won’t Bite Y’er Butt?”, a special emphasis is placed on including actions organizations can take immediately to mitigating firmware vulnerabilities and infections, above and beyond patching.

More Information:

http://www.legbacore.com/Research.html

Sage Engineering updates Minnow firmware

Sage Engineering maintains a Coreboot-based, SeaBIOS payload-based firmware for the Intel MinnowBoard MAX.

Today, they’ve announced an updated release. This update allows for flashing the boot image without a hardware device.

The binary SageBIOS boot ROM image, which is flashed on the development board’s SPI Flash device, is based on the Intel Firmware Support Package (Intel FSP) and coreboot open source initialization. The SageBIOS OSP replaces UEFI firmware that comes installed on both versions of MinnowBoard MAX and will support booting a greater variety of operating systems, including FreeBSD and a variety of RTOS, as well as legacy operating systems such as older versions of Microsoft Windows and even DOS. The SageBIOS OSP will support all the operating systems supported by the native UEFI firmware, such as Windows and Linux. In addition, the SageBIOS OSP will boot both 32-bit and 64-bit operating systems with a single boot image.

The download of the “demo ROM” is free, but email registration is required.
More information:
http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20150518/001523.html
http://www.se-eng.com/minnow/

Spring UEFI Forum agenda announced

The UEFI Forum Spring event is happening in Tacoma.WA.US this coming week. They just announced the presentations for the event:

* Zachary Bobroff, AMI – PreBoot Provisioning solution with UEFI
* Kevin Davis, Insyde – System Prep Applications, A Powerful New Feature in UEFI 2.5
* Olivier Martin, ARM – Porting a PCI driver to ARM AArch64 platforms
* Lief Lindholm, ARM – Demonstrating a common EDK2 pltforms & drivers tree
* Dick Wilkins, Phoenix – UEFI FIrmware – Securing SMM
* Gabe Stocco and Scott Anderson, Microsoft – Windows Requirements for TPM, HVCI and Secure Boot
* Jeremiah Cox
* Vincent Zimmer, Intel – Filling UEFI/FW Gaps in the Cloud
* David Box, Intel – An overview of ACPICA userspace tools
* Samer El-Haj-Mahmoud, HP – Firmware in the Datacenter: Goodbye PXE and IPMI. Welcome Http

Typically, the UEFI Forum makes slides for these presentations available on their web site a few weeks later…

More information:
http://www.uefi.org/node/887

 

AMI launches MG9005 controller for NVMe SSD storage

Today AMI (American Megatrends, Inc.) launches a new enclosure solution for NVM Express SSD Subsystems. The controller is firmware-upgradable through SMBUS.

A true, single-chip solution, the MG9095 backplane controller ships ready to use with no custom firmware or programming required,” said Subramonian Shankar, AMI CEO.

Read the full announcement:
http://www.ami.com/products/backplanes-and-enclosure-management/enclosure-management-asics/mg9095-controller/

http://www.ami.com/news/press-releases/?PressReleaseID=312&/American%20Megatrends%20Launches%20Enclosure%20Management%20Solution%20for%20NVM%20Express%E2%84%A2%20SSD%20Subsystems/

Red Hat OVMF whitepaper

[This is not fresh news. Since this is a new blog, I’m starting to work backward on some noteworthy news/releases that happened shortly before the blog started…]

Mid-2014, Red Hat released a whitepaper documenting the UEFI OVMF format. It is well-written, and useful for those new to UEFI, coming from a Linux background. The document is Copyright (C) 2014-2015, Red Hat, Inc., licensed CC BY-SA 4.0.

Abstract: The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI is designed to replace the Basic Input/Output System (BIOS) firmware interface. Hardware platform vendors have been increasingly adopting the UEFI Specification to govern their boot firmware developments. OVMF (Open Virtual Machine Firmware), a sub-project of Intel’s EFI Development Kit II (edk2), enables UEFI support for Ia32 and X64 Virtual Machines. This paper reports on the status of the OVMF project, treats features and limitations, gives end-user hints, and examines some areas in-depth.

Keywords: ACPI, boot options, CSM, edk2, firmware, flash, fw_cfg, KVM, memory map, non-volatile variables, OVMF, PCD, QEMU, reset vector, S3, Secure Boot, Smbios, SMM, TianoCore, UEFI, VBE shim, Virtio

Read the whitepaper:

http://people.redhat.com/~lersek/ovmf-whitepaper-c770f8c.txt

RMS on Free Hardware from LibrePlanet 2015

The Free Software Foundation has released some of the videos from LibrePlanet 2015. The presentation from RMS is described as:

Free software, free hardware, and other things by Richard Stallman, founder of the Free Software Foundation. Richard gives his take on some major issues facing the world of free software and explains how the free software philosophy extends to hardware.

It is a 45-minute video, the first 23 minutes are presentation, the remainder are QA. Video is here:
https://media.libreplanet.org/u/libreplanet/m/richard-stallman-free-software-free-hardware/

I have few questions of my own, from watching it:

At the beginning, he mentions that remote attestation of TPM doesn’t work, without any details on why he thinks that. I don’t understand what he’s talking about, there are multiple TNC implemenations, as well as non-TNC equivalent solutions that use TPM for network attestation. Linux-based Chrome OS, StrongSwan for Linux, Linux-IMA or OpenAttestation (OAT) for example.
If someone has more background on his perspective on remote attestation of TPM doesn’t work, please speak up. Heck, even the UEFI firmware on most modern systems have TNC support. IMO, it would have been more interesting to hear a discussion about new TPM 2.0 features, as well as TrustZone on ARM, and how that impacts various Free Software/Firmware/Hardware movements.
https://github.com/OpenAttestation/OpenAttestation/wiki
https://wiki.strongswan.org/projects/strongswan/wiki/TrustedNetworkConnect
http://linux-ima.sourceforge.net/

Later, he talks about “Free Hardware” term, which AFAICT isn’t that well-defined, and recommends using GPLv3 for hardware, and doesn’t mention OSHWA license, except to say that the alternatives offer no value. I am not sure that the existing OSHWA has the same opinion as RMS with his “Free Hardware” perspective, see March-April thread on the OSHWA list. IMO, Free Hardware -vs- Open Hardware needs some clarification. I guess, like with software, we’ll have the Open camps and the Free camp, with FSF as the Free owner and OSHWA instead of OSI for the Open camps, in addition to the Closed camps. However, unlike ISVs, I’ve never met an OEM or IHV that likes the GPL, so any Free Hardware will likely have to be community-funded, like Novena; I hope the FSF plans community-funded Free Hardware in the coming months.
https://www.fsf.org/bulletin/2012/fall/a-bit-about-free-hardware
http://www.wired.com/2015/03/need-free-digital-hardware-designs/
http://www.wired.com/2015/03/richard-stallman-how-to-make-hardware-designs-free/
http://lists.oshwa.org/pipermail/discuss/2015-March/thread.html
https://www.crowdsupply.com/kosagi/novena

 

CrowdStrike announces Venom vulnerability

As reported by Robert Hackett at Fortune, Crowdstrike has research on a new vulnerability that impacts virtualization. Venom stands for “virtualized environment neglected operations manipulation”. It impacts QEMU, Xen, KVM, and VirtualBox, among others.

(It must be a big deal, as it already has an icon. I think Heartbleed took longer for it’s icon.)

More information:
http://venom.crowdstrike.com/
http://fortune.com/2015/05/13/venom-vulnerability/

Windows Defender attacks some non-Windows UEFI images

Starting in late 2013, Microsoft Windows Defender, a background malware scanner that gets updates via Windows Update, started looking for UEFI boot managers/loaders/tools that are not signed by Microsoft, and started deleting them. This impacts booting non-Windows OSes, Linux, FreeBSD, Android, etc. Windows Defender gives users no control to override/configure anything. Microsoft can update the scanner to delete new files in the future, when Windows Update refreshes it. Presumably any UEFI image that isn’t signed by Microsoft is likely a candidate.  I am unclear what “UEFI module” is they describe in the documentation (see below), I presume this means any UEFI Application/Service/Driver. The list of OEM contacts the Microsoft documentation points to for these “UEFI modules” is a very old list, doesn’t cover most UEFI Forum Members. Then again, some of the main targets of Defenders deletions are likely not OEMs nor UEFI Forum Members, but open source UEFI tools.

This feature is useful if you have a Windows system and you only run Windows, and never want to run anything other than Windows. This feature is not useful if you ever wish to dual-boot a non-Windows OS alongside Windows, since Windows Defender will destroy the other OS’s boot loader.

The workaround is to never dual-boot anything alongside Windows. OEMs who want to build non-Windows machines have to risk Windows Defender making their systems unbootable, if any customer tries to dual-boot Windows on it. I wonder, if an OEM is ever capable enough to ship a Linux system with UEFI Secure Boot setup to boot Linux, without Microsoft keys, would Windows Defender properly check the UEFI keys and delete the Windows boot manager, which is unsigned by that firmware? 🙂

More information:

Microsoft security advisory: Update to revoke noncompliant UEFI boot loader modules
https://support.microsoft.com/en-us/kb/2871690
https://technet.microsoft.com/library/security/2871690

Excerpts:

“Microsoft is announcing the availability of an update for Windows 8 and Windows Server 2012 that revokes the digital signatures for nine private, third-party UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked. At the time of this release, these UEFI modules are not known to be available publicly. Microsoft is not aware of any misuse of the affected UEFI modules. Microsoft is proactively revoking these non-compliant modules as part of ongoing efforts to protect customers. This action only affects systems running Windows 8 and Windows Server 2012 that are capable of UEFI Secure Boot where the system is configured to boot via UEFI and Secure Boot is enabled. There is no action on systems that do not support UEFI Secure Boot or where it is disabled.”

“On affected releases of Microsoft Windows that are running on UEFI firmware with UEFI Secure Boot enabled, the update revokes the digital signatures for specific UEFI modules that could be loaded during UEFI Secure Boot. When the update is applied, the affected UEFI modules will no longer be trusted and will no longer load on systems where UEFI Secure Boot is enabled. The affected UEFI modules consist of specific Microsoft-signed modules that are either not in compliance with our certification program or their authors have requested that the packages be revoked.”

“For more information about your UEFI module, contact the UEFI module supplier. This might include the system vendor, the plug-in card vendor, or other UEFI software vendors such as UEFI backup and restore solutions, UEFI anti-malware, and so on.”

“Customers should update their UEFI modules to compliant versions prior to installation of this update. Customers who apply this update on a system with a non-compliant UEFI module risk putting the system into a non-bootable state. Microsoft recommends that all customers apply this update after ensuring they are running up-to-date UEFI modules.”

“Customers who want to continue using non-compliant UEFI modules for their own purposes, such as for testing, can do so by disabling Secure Boot in their system’s BIOS configuration menu.

Firmware security checks and IoT network security

In Mobile Enterprise, Laurie Lamberth and Steve Brumer have a story on IoT network security. Previous articles on topic have mentioned issues with out-of-date device firmware.

Excerpt:

3. Periodic endpoint integrity checks: With thousands of devices of all different types being connected to the enterprise networks, over different networks with different access control protocols, after the fact as well as real-time access monitoring is a good idea. Periodically checking each device’s security software and policies, firmware, software, and other resources such as anti-virus protection, can root out vulnerabilities before they become problems.

Read the full story:
http://mobileenterprise.edgl.com/news/3-Options-for-Securing-the-IoT-Network-99910

Do you know how to check the firmware on your system?

Linaro makes LUVos-live available for ARM64

LUVos (Linux UEFI Validation — aka luvOS or LUVos, is a Yocto-based Linux distro that helps diagnose UEFI firmware. LUV-live is a liveimage boot version of LUVos. LUV-live also includes other hardware/firmware tools, such as BITS, FWTS, and CHIPSEC.

Intel-based LUV was initially only targeting Intel platforms. But LUV is an open source project, with a healthy community of contributors.

Recently Linaro has been porting LUV to ARM64. Thanks, Linaro! This is great news for ARM64 Linux enterprise hardware. Once Linaro ports CHIPSEC to ARM, it’ll be a very good day for ARM64 firmware defensive security tools.

It would be nice to consider an ARM32 port, as well as ARM64. All devices need bootkit detection tools, not just enterprise-class systems. 🙂

[Someone please wake up AMD. Right now, AFAICT, their platform now has the worst defensive tools. They need a LUV-live with a CHIPSEC that works on ARM systems.]

https://wiki.linaro.org/LEG/Engineering/luvOS

https://01.org/linux-uefi-validation

Book Review: Embedded Firmware Solutions

Embedded Firmware Solutions: Development Best Practices for the Internet of Things
APress Media
ISBN 978-4842-0071-1
February 2015
Jiming Sun, Marc Jones, Stefan Reinauer, Vincent Zimmer
http://www.apress.com/9781484200711

[I recently finished reading this book. Sadly, I didn’t know about it until the other day, after my LinuxFestNorthWest talk on firmware security tools, someone from Sage pointed out that I omitted this from my More Information slides.]

If you care about firmware development — or just understanding current firmware architecture — you should have this book. It is the only current book with information about modern firmware in use today. The authors are all experienced and well-known firmware developers, including members of the Coreboot and UEFI teams, and there is also an impressive list of tech reviewers. There are 4 areas that this book focuses on:
* Intel Firmware Support Package (FSP), and it’s use in Coreboot and UEFI.
* UEFI and it’s dev platform.
* Coreboot and Chrome use of it.
* Intel Quark and UEFI firmware.

Intel Press has a handful of other UEFI books, but they are years old, this book is only a few months old, and has fresher details on UEFI. I don’t know of any other book with this kind of information on Coreboot, or on Intel FSP. There are a variety of books on Intel’s Minnowboard and Quark/Galileo IoT hardware: most of those books talk about how to write user-level apps, this is the only book that talks about updating the firmware of Intel IoT devices.

I’m looking forward to a second edition in a year or so, once tech changes enough.

New NVME Express pass-through protocol in UEFI 2.5

Feng Tian of Intel recently checked in changes to the EDK-II trunk for the EFI_NVME_PASS_THRU_PROTOCOL, as part of the UEFI 2.5 checkins. This UEFI NVM Express protocol provides services that allow NVM Express commands to be sent to an NVM Express controller or to a specific namespace in a NVM Express controller.

I’ve found the definitions in the code, but not an implementation, so either the checkin hasn’t happened yet, I’ve missed it, or it’s a non-open source implementation that won’t be in the TianoCore code, I’m unclear. If you know, please speak up!

For more information, see:
MdePkg/Include/Protocol/NvmExpressPassthru.h
and:

Front

New UEFI HTTP Boot support in UEFI 2.5

One of the new features in UEFI 2.5 is the use of the HTTP protocol for network booting. Previously, UEFI booted remotely, using IPv4 or IPv6, starting with DHCP, then finishing using TFTP, “PXE-based”. This new UEFI 2.5 change defines new DHCP options to specify URI-based pointers to the “Network Boot Program (NBP)”, the binary image to download and run, which can be used using HTTP instead of TFTP. DHCP Servers will need to support this new HTTPBoot extension, if the DHCP type code for x86 is 0x0F and 0x10 for x64. For example, inside a corporate enterprise, with an URL like:
http://examplebootserver/boot/boot.efi

HTTP aside, the new spec hints of future URI-based network protocol support, such as FTP or NFS, in the future.

AFAICT, this presumes HTTP, not HTTPS. Most of the spec says HTTP. Only in one place did I see a reference to TLS and HTTPS, see Figure 72. But TLS and the S in HTTPS were in red, unlike all else, unclear what this means, if it is not public feature only in commercial UEFI products, etc.  Speak up if you know.

The spec mentions both enterprise and home use of this protocol, and they mention usage of this protocol across across networks (via the public Internet), not just internal home/corporate network use.

Refer to section 23.7 of the UEFI v2.5 specification for more details.
http://www.uefi.org/specsandtesttools

I’ve yet to locate this code in the public TianoCore EDK-II trunk; either I’ve missed it, it hasn’t yet been checked in, or the code is part of a non-open source codebase. It would answer the HTTPS/TLS question, as well. Speak up if you know the answer!

UEFI systems’s updates can incorporate new features, so this feature may show up in your system the next time your vendor issues an update. So, DNS, DHCP, and HTTP are all network attack vectors for network UEFI booting. Is your firewall/router ready for UEFI HTTP Booting?

New storage crypto Interface protocol added to UEFI 2.5

A few days ago, as part of the UEFI 2.5 checkins, Tien Feng of Intel checked in new code to the EDK-II trunk, with a new UEFI Inline Cryptographic Interface protocol.

“The EFI_BLOCK_IO_CRYPTO_PROTOCOL defines a UEFI protocol that can be used by UEFI drivers and applications to perform block encryption on a storage device, such as UFS.”

The interface protocol provides services to abstract access to inline cryptographic capabilities. It has the abilities to get, configure and use pre-OS crypto support in disks, and can configure algorithms, key sizes and keys. It has interfaces such as Reset, GetCapabilities, SetConfiguration, GetConfiguration, ReadExtended, WriteExtended, and FlushBlocks. The latter are read/write/flush functions which encrypt/decrypt the data.

For more information, read MdePkg/Include/Protocol/BlockIoCrypto.h and search for EFI_BLOCK_IO_CRYPTO_PROTOCOL_GUID.