Hastily-written news/info on the firmware security/development communities, sorry for the typos.
A bit more on this:
Lenovo has updated their support document. The initial version had no technical details. The update now has a huge list of models which are affected or not. The researcher also mentions that an update from the vendor is expected next month. I’m still waiting to see the IBV’s and other OEMs responses to this.
https://support.lenovo.com/us/en/solutions/LEN-8324
Lenovo has a response:
System Management Mode (SMM) BIOS Vulnerability
Lenovo Security Advisory: LEN-8324
Potential Impact: Execution of code in SMM by an attacker with local administrative access
Severity: High
Scope of Impact: Industry-wide
https://support.lenovo.com/us/en/solutions/LEN-8324
The researcher also has a few responses:
A few bits of news to add to this:
These days, it is nice to know that a firmware bug is probably an accidental defect, rather than some backdoor. 🙂
In 2015, UEFI Forum used to do Security Advisories, with 2 PDFs each containing more than a dozen potential exploits. I wonder how many of those are in today’s vendors codebases? No more advisories from UEFI Forum since 2015, so who knows what other cut-and-paste OEM/IBV bugs are being propogated? I wish UEFI Forum would issue more Security Advisories, multiple bugfixes on the EDK2-devel project appear to merit this kind of attention.
Cr4sh has written the second article in his series on Lenovo firmware security research:
Exploring and exploiting Lenovo firmware secrets
Hi, everyone! In this article I will continue to publish my research of Lenovo ThinkPad’s firmware. Previously I shown how to discover and exploit SMM callout vulnerabilities on example of SystemSmmAhciAspiLegacyRt UEFI driver 1day vulnerability. Also, I introduced a small toolkit called fwexpl that provides API for comfortable development of firmware exploits for Windows platform. My previous Lenovo exploit was able to execute custom code in SMM, such conditions allow relatively easy bypass of BIOS_CNTL security mechanism which protect firmware code stored inside SPI flash chip on motherboard from unauthorized modifications by operating system (BIOS_CNTL bypass also was discussed in my another article “Breaking UEFI security with software DMA attacks”). In addition to BIOS_CNTL, modern Lenovo computers also use SPI Protected Ranges (aka PRx) flash write protection, so, in this article I will present my generic exploitation technique that allows to bypass PRx and turn arbitrary SMM code execution vulnerability into the flash write protection bypass exploit. This technique also can be applied to UEFI compatible computers of other manufacturers — they all use similar design of specific firmware features that responsible for platform security. In second part of the article I will present a new 0day vulnerability in Lenovo firmware that allows arbitrary SMM code execution on a wide range of Lenovo models and firmware versions including the most recent ones. Exploitation of this vulnerability may lead to the flash write protection bypass, disabling of UEFI Secure Boot, Virtual Secure Mode and Credential Guard bypass in Windows 10 Enterprise and other evil things. […]
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
https://github.com/Cr4sh/ThinkPwn
See-also:
DebConf, Debian’s annual conference is happening in Cape Town, South Africa. Even if you aren’t in Cape Town this week, the DebConf event team is very good at providing postconference video archives, look for them to be available shortly.
https://bits.debian.org/2016/06/debconf16-schedule.html
https://debconf16.debconf.org/
Amongst the many interesting presentations, here’s a few firmware-related presentations to look forward to:
Secure Boot BOF
Ben Hutchings
Secure Boot is a UEFI feature that prevents unsigned boot code from being loaded. Assuming the bootloader checks the signature on the kernel, and the kernel checks the signature on code it itself loads, this chain of trust can be extended quite far into the running system. Unfortunately, the only signing key that is trusted by most implementations is held by Microsoft.
There are 2 major reasons for supporting Secure Boot in Debian:
* some computers now ship with Secure Boot enabled by default, making it harder to install Debian;
* while not perfect, it is a technology that can be used to make Debian user safer.
The plan the Ben (bwh) has been hatching is as follows:
* a minimalistic shim bootloader is signed by Microsoft;
* the shim load a bootloader that was properly signed by Debian (in the long run, ftpmaster@; right now, it’s bwh’s signing key);
* the bootloader loads a kernel signed by Debian;
* the kernel only accepts to load code signed by Debian (securelevel = 1).
The signing process itself uses signature packages, so as not to keep signing keys on the buildds or break reproducibility.
Advantages:
* no dependency on Microsoft, once the shim is signed (and it should need fixes very seldom);
* robust process that can take advantage of reproducible builds;
* gives reasonable guarantees that the running kernel is a legitimate one;
* trusting only Debian (as opposed to anything Microsoft signs) can easily be achieved by shipping a Debian-signed shim and having the user put the Debian key as the only trusted one.
Caveats:
* doesn’t protect the userspace (yet!);
* still vulnerable to somebody with a kernel exploit (but this doesn’t grant persistence) or who can get a bootloader signed by Microsoft.
Help us, fellow Debian hackers! You are our only hope.
https://debconf16.debconf.org/talks/79/
Secure Boot for Debian Linux
Ben Hutchings
Three years after a “Plan of action” for Secure Boot support, we’ve had another release without it and there are still many changes required. What is left to do and how will we finish it in time for “stretch”?
https://debconf16.debconf.org/talks/33/
Using LAVA for Debian
Neil Williams
How to use LAVA to provide test support on real hardware which can be remote or local to the user.
* lava.debian.net
* publish local tests from your desk to support testing packages like u-boot.
* install lava-dispatcher on a machine on your LAN and publish local tests for everyone to view and analyse
* run CI on the Linux kernel packages on hardware – ramdisk, NFS and SATA media
* test DI on real hardware (typically ARM).
* publish local tests of VM images, including live images, and potentially run tests on VM images where appropriate hardware is available.
* run server-client tests on relevant hardware which cannot be easily performed in sbuild or single VM instances.
* support for VLAN testing is available although unlikely to be via lava.debian.net itself.
* support for Debian SSO for account creation.
* XMLRPC and REST API interfaces.
https://debconf16.debconf.org/talks/10/
Debugging the IoT
Bdale Garbee Bernelle Verster Andy Simpkins
Panel discussion, aimed at the general public and more technical participants alike. The panel will discuss the open hardware movement, and how it fits in with Smart Homes. It will highlight and discuss the futurology, trends, and challenges. Challenges include security, the role of big vendors, the requirement for a more powerful platform, competing interests and the role of industrial providers. The panel will be hosted by Bernelle Verster, and panelists include Andy Simpkins and others. (Please get in touch if you want to be on the panel too).
https://debconf16.debconf.org/talks/119/
Debian on ARM devices
Martin Michlmayr
This talk will cover Debian on ARM devices, including NAS devices, development boards and other devices. The talk will briefly explain how the installer works on ARM from the point of view of a user. It will then cover in detail how Debian on ARM is different to Debian on x86 devices and what infrastructure we created in Debian to support a wide range of ARM devices, such as flash-kernel. Some supported platforms and devices will be covered as well.
https://debconf16.debconf.org/talks/90/
The UEFI Form has a new whitepaper on UEFI and the Chain of Trust:
https://twitter.com/Intel_UEFI/status/743874217603538946
The Chain of Trust: Keeping Computing Systems More Secure
UEFI Forum white paper explaining the Chain of Trust and its role in keeping computing systems secure
http://www.uefi.org/learning_center/papers
http://www.uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_Final.pdf
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/
“A short while ago, slipstream/RoL dropped an exploit for the ASUS memory mapping driver (ASMMAP/ASMMAP64) which was vulnerable to complete physical memory access (read/write) to unprivileged users, allowing for local privilege escalation and all sorts of other problems. An aside to this was that there were also IOCTLs available to perform direct I/O operations (in/out instructions) directly from unprivileged usermode, which had additional interesting impacts for messing with system firmware without triggering AV heuristics.
[…]
In addition to the ASMMAP bugs, I also reported the exact same bugs in their UEFI update driver (AsUpIO.sys). This driver is deployed as part of the usermode UEFI update toolset, and exposes almost identical functionality which (as slipstream/RoL pointed out) is likely from an NT3.1 example driver that was written long before Microsoft took steps to segregate malicious users from physical memory in any meaningful way.”
[…]
Olimex has a new blog post on Linux/UEFI debugging:
They were nice enough to add it as a Comment to this post:
Finnbarr has a new blog post, on diagnosing UEFI-centric issues with modern Windows systems, with lots of figures and screenshots and background information:
[…] I hope this detailed explanation of how Windows 10 boots on a UEFI-platform will help you keep your sanity the next time you boot and see a missing or corrupt BCD message. Remember to always configure your platform so that you can boot into a UEFI shell using the UEFI firmware-based boot manager and make a backup of your BCD store.
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
[Update: SMM driver dev advice for this from issue is here:
]
Bruno of Sogeti ESEC Lab has published an interesting paper with an SMM exploit, well-written with lots of background on UEFI and SMM exploits, lots of images/figures and links, definately worth reading:
SMM unchecked pointer vulnerability
Mon 30 May 2016 by Bruno
This article explains the exploitation of an SMM unchecked pointer vulnerability present in several firmwares. As this vulnerability is a memory corruption, it only applies to firmwares including the unpatched vulnerable DXE driver. It first explains the SMM mode and some of its mechanisms, then the reversing of the UEFI driver in which the vulnerability is present, then the exploitation of the vulnerability in it-self and finally a little conclusion about the impact of the vulnerability. […]
This vulnerability was initially found on two different firmwares of different OEM, both of them seem to have a lot in common. Their firmware were based on one version of the EDK implementation by Intel with several new features added. After some research it appears that both were using code provided by American Megatrends Inc. (AMI) . We contacted AMI and the OEM and got quick responses from them. We would like to thank them for working with us, especially Lenovo for coordinating with us. […]
This vulnerability allows to gain code execution in SMM. In the case of both studied firmwares the flash was not protected by the Protected Range (PR) registers, code execution in SMM allows rewriting the flash and potentially the setup of a persistent bootkit.
On January 2016 VirusTotal (VT) began to provide information on firmware images as described in their blog post . We used this for finding firmware which includes the SMIFlash driver. In total we found approximately 900 different firmwares (type:rom) which contains it, 468 of those had different versions, however it is likely that a lot of these firmwares are just different versions of one another. We have gathered the Vendor identification provided by VT for each of those firmware and got approximately 10 different constructors however 84% of the firmwares have AMI as vendor. […]
http://esec-lab.sogeti.com/posts/2016/05/30/smm-unchecked-pointer-vulnerability.html
Brian Richardson of Intel UEFI team has a new blog post, showing HP vendor data using DMTF Redfish as well as viewing UEFI x-UEFI Configuration Language data.
http://blogs.intel.com/evangelists/2016/05/25/firmware-modern-data-center/
For more on the x-UEFI Configuration language, see Vincent’s post:
A few document updates from Microsoft on Secure Boot and one news article on Windows hardware requirements:
Justin Hall of Microsoft has updated their document on how to disable Secure Boot:
Justin has also updated their guidance on Secure Boot keys:
Milad Aslaner of Microsoft has updated their document on how to access UEFI security features in their Surface devices:
https://technet.microsoft.com/en-us/itpro/surface/advanced-uefi-security-features-for-surface
The Windows driver doc team has updated their document on Booting and UEFI:
https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/boot-and-uefi
Extreme Tech has a story on Windows hardware requirements increasing:
It mentions that Windows 10 Mobile OEMs must not disable Secure Boot. I have not been following Microsoft’s changes to Secure Boot guidance too closely, this might be a change.
Claunia has written aclock-efi, a UEFI port of aclock, an analock clock.
Aclock is an analog clock program for text mode console displays, terminals, or terminal emulators. This program is obviously absolutely useless, except for turning your old, expensive mainframe or supercomputer into a wall clock. The UNIX source code compiles on everything from AIX to zOS without any changes. Available are Curses, Termcap and AAlib for more modern systems. Provided are also specific, non-unix ports. There is also a vector graphics version for Tektronix 4014/4010 or XTerm/Kermit Tek emulator. This version is a port from the Curses aclock version to EFI Boot Services.
Metabolix has written HackBGRT, a tool that changes the Windows boot logo on UEFI systems. It works on Intel 64-bit UEFI systems, with Secure Boot disabled.
“HackBGRT is intended as a boot logo changer for UEFI-based Windows systems. When booting on a UEFI-based computer, Windows may show a vendor-defined logo which is stored on the UEFI firmware in a section called Boot Graphics Resource Table (BGRT). It’s usually very difficult to change the image permamently, but a custom UEFI application may be used to overwrite it during the boot. HackBGRT does exactly that. Important: If you mess up the installation, your system may become unbootable! Create a rescue disk before use. This software comes with no warranty. Use at your own risk.” […]
Sugawaray has written EFIboot, which runs Linux-style ELF binaries inside the UEFI Shell. Here’s the *full* readme:
A tool to execute an elf binary in the UEFI shell environment.
This tool executes an elf binary in the UEFI SHELL.
The name of the elf binary must be ‘test.elf’.
For more information, read the code:
https://github.com/sugawaray/efiboot
James Johnson has a project to help make Secure Boot on Ubuntu. Excerpt of readme:
ubuntu-secure-boot package
The stock Ubuntu 15.10 installation only implements secure boot just enough to get a Microsoft-signed shim in place. It does nothing to actually secure the boot process. This package can help users do so.
Features of ubuntu-secure-boot:
* Self-signed bootloader files: take control over your boot process by stripping Canonical / Microsoft signatures from your boot files and signing everything yourself.
* Summary of files that are digitally signed and verified during the boot process are:
* GRUB itself (self-signed)
* GRUB configuration (self-signed)
* GRUB modules and other external files (self-signed)
* Linux kernel (self-signed)
* Linux initramfs / initrd (self-signed)
* Linux kernel modules (using existing Canonical signatures)
* Self-signed private keys are stored in /etc/ubuntu-secure-boot/keys and protected by a passphrase.
* UEFI Secure Boot self-signed key pairs are generated and used to sign the self-contained GRUB .efi image. They can be imported into a UEFI firmware to take full control over the secure boot process.
* The secure GRUB image is added as a boot option in EFI firmware.
* Digital signature support in GRUB is enabled to check signatures on any boot file that is loaded from disk. The risk of loading an unsigned file from GRUB is eliminated (e.g. an unsigned kernel).
* GRUB is now deployed as a stand-alone .efi image that contains a memdisk with the full configuration and all loadable modules. This eliminates the risk of tampering with the GRUB configuration.
* GRUB is automatically locked down with a password so that users cannot tamper with boot settings or use advanced boot options.
* Unsigned GRUB files in /boot remaining from the original GRUB packages are completely wiped (but restored upon uninstall of this package).
* Newly-installed kernels are automatically signed whenever they are installed. Existing Canonical .efi signatures in the linux-signed-image-* packages are stripped and replaced with your signature.
* The initramfs is automatically re-signed whenever update-initramfs is run.
* Linux kernel module signing enforcement is automatically enabled by default. This can be controlled from /etc/default/grub.d/ubuntu-secure-boot.cfg.
Ivan Hu of Canonical has two related projects on Github, UEFIOP and EFI_runtime, the former app depends on the latter Linux kernel driver:
The uefiop is an application that allows users to manipulate UEFI runtime interfaces provided by Bios at runtime. Current capabilities:
* set and delete uefi variables
The Efi_runtime kernel driver module aims to provide the interfaces for fwts (firmware test suite) to test the UEFI Runtime services provide by firmware. Current capabilities:
* provide the RT service interfaces:
* GetVariable
* SetVariable
* GetTime
* SetTime
* GetWakeupTime
* SetWakeupTime
* GetNextVariableName
https://github.com/Ivanhu5866/uefiop
https://github.com/Ivanhu5866/efi_runtime
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Discover the Desktop
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
News from coreboot world
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Just another WordPress.com site
Hastily-written news/info on the firmware security/development communities, sorry for the typos.
Firmware Security 
You must be logged in to post a comment.