CVE-2016-8226, Lenovo UEFI DoS

CVE Identifier: CVE-2016-8226
Access Vector: Network exploitable
Access Complexity: Low
Original release date: 01/26/2017

The BIOS in Lenovo System X M5, M6, and X6 systems allows administrators to cause a denial of service via updating a UEFI data structure.

 

Lenovo Security Advisory: LEN-11306
Denial of service attack on Lenovo System X M5, M6, and X6 systems
 
A vulnerability was identified in the BIOS of Lenovo System X M5, M6, and X6 systems. An attacker with administrative access to a system can cause a denial of service attack on the system by updating a UEFI data structure. After this occurs, the system will not complete POST (Power-On Self-Test) , hang at the Lenovo splash screen, and fail to boot. This issue was inadvertently encountered in an update to Microsoft Windows Server 2012, Windows Server 2012R2 and Windows Server 2016 (see https://support.lenovo.com/us/en/solutions/ht502912 for details). However, systems running any operating system are vulnerable. Lenovo strongly recommends installing this update. Mitigation Strategy for Customers (what you should do to protect yourself):[…]
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8226

https://support.lenovo.com/us/en/solutions/LEN-11306

 

Microsoft Updates OEM Device/Credential Guard requirements

Microsoft just updated this page:

https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/minimum/device-guard-and-credential-guard

No list of what’s changed, it seems that would be a reasonable thing for a large list of requirements…  I’ll leave you to figure out what changed. 🙂

(If someone knows of a good way to diff this page against the same page a few weeks ago (without archive.org), please leave a Comment on this blog post. Thanks.)

 

UEFI support for DragonFlyBSD

https://www.dragonflydigest.com/2017/01/05/19139.html
http://lists.dragonflybsd.org/pipermail/users/2017-January/313193.html
http://apollo.backplane.com/DFlyMisc/uefi.txt
https://www.dragonflydigest.com/2017/01/17/19208.html
http://lists.dragonflybsd.org/pipermail/commits/2017-January/625352.html
https://leaf.dragonflybsd.org/cgi/web-man?command=uefi&section=ANY

No Secure Boot support yet.

Asset Intertech on debugging Minnowboard firmware

Asset Intertech has a blog series on debugging Minnowboard firmware using their debugger product. Even if you can’t afford their product, you can still learn about debugging UEFI firmware from this post. 🙂

The Minnowboard Chronicles – Episode 3

As I continue the journey to learn about the internals of UEFI and to debug it with SourcePoint, I encounter some issues doing the firmware build. Last week, I played around with the UEFI shell, and then updated the firmware on my Minnowboard to the latest release (v0.94). Then, I used SourcePoint to look at disassembled code when the platform was sitting in the UEFI shell, waiting for keyboard input. From last time, we can see a number of “INT 3” instructions, with opcode CC. […]

http://blog.asset-intertech.com/test_data_out/2017/01/sourcepoint-debugging-the-minnowboard-turbot.html

http://blog.asset-intertech.com/test_data_out/2017/01/the-minnowboard-chronicles-episode-2.html

http://blog.asset-intertech.com/test_data_out/2017/01/the-minnowboard-chronicles-episode-3.html

AMI announces UEFI 2.6 and ACPI 6.1 support

AMI announced that their UEFI implementation, Aptio V, supports UEFI 2.6 and ACPI 6.1

American Megatrends Announces Aptio V Compliance with UEFI 2.6 and ACPI v6.1

AMI is proud to announce Aptio® V support and compliance for UEFI 2.6 and ACPI v6.1 specifications. As a leader in the BIOS/UEFI firmware industry and board member in the UEFI community, AMI keeps up with the latest upgrades and specifications to better serve its customers in the technology industry. Aptio® V, AMI’s flagship UEFI firmware, is developed according to UEFI specifications and the added support for UEFI 2.6 and ACPI v6.1 gives manufacturers the ability to enhance select platforms based on the latest UEFI specifications. The newest specifications, announced this past March, keeps up with the increasing expectations of the market, providing OEMs and ODMs greater manageability across various user systems and creating more expansive support for newer platforms and designs. By integrating and expanding support for UEFI 2.6 and ACPI v6.1 on its core UEFI firmware, Aptio V, AMI standardizes operating systems booting and optimizes pre-boot applications for its customers.

Full PR:

https://ami.com/news/press-releases/?PressReleaseID=373

 

EDK2 test harness

Michael Kinney of Intel has created an edk2-test branch, to focus on testing!

I am creating a new branch in edk2-staging called edk2-test. The purpose of this branch is to develop a test harness, test case SDK, and library of test cases that can be used as part of edk2 validation. The initial version of this test harness is compatible with binary releases of the PI SCTs and UEFI SCTs, are native edk2 packages with no dependencies on the EdkCompatibilityPkg, and the test harness runs using the latest version of the UEFI Shell. 

Additional work items:
* Update to take advantage of latest edk2 features/libraries.
* Update for all supported CPU types
* Update for all supported compilers
* Review initial test harness features and determine what features should be dropped and what new features should be added.
* Determine where the test harness, test case SDK, and test cases should live once the initial functional and quality criteria are met.  Could be packages in the edk2 repo or packages in a new edk2-test repo.  Other options???
* Resolve compatibility issues with binary releases of the PI SCTs and UEFI SCTs.
* Update test harness to support PEI tests
* Update test harness to support Runtime tests
* Update test harness to support SMM tests
* Optimize performance of the test harness and tests.

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

Yuriy and Oleksandr at REcon

Baring the system: New vulnerabilities in SMM of Coreboot and UEFI based systems
By: Yuriy Bulygin, Oleksandr Bazhaniuk

Previously, we discovered a number of vulnerabilities in UEFI based firmware including software vulnerabilities in SMI handlers that could lead to SMM code execution, attacks on hypervisors like Xen, Hyper-V and bypassing modern security protections in Windows 10 such as Virtual Secure Mode with Credential and Device Guard. These issues led to changes in the way OS communicates with SMM on UEFI based systems and new Windows SMM Security Mitigations ACPI Table (WSMT). This research describes an entirely new class of vulnerabilities affecting SMI handlers on systems with Coreboot and UEFI based firmware. These issues are caused by incorrect trust assumptions between the firmware and underlying hardware which makes them applicable to any type of system firmware. We will describe impact and various mitigation techniques. We will also release a module for open source CHIPSEC framework to automatically detect this type of issues on a running system.

https://recon.cx/2017/brussels/talks/baring_the_system.html

Yuriy to speak at REcon Brussels

 

 

Attacking UEFI Runtime Services

Ulf has an informative new article (and video) about attacking UEFI Runtime Services on Linux-based systems using PCILeech:

Attackers with physical access are able to attack the firmware on many fully patched computers with DMA – Direct Memory Access. Once code execution is gained in UEFI/EFI Runtime Services it is possible to use this foothold to take control of a running Linux system. The Linux 4.8 kernel fully randomizes the physical memory location of the kernel. There is a high likelyhood that the kernel will be randomized above 4GB on computers with sufficient memory. This means that DMA attack hardware only capable of 32-bit addressing (4GB), such as PCILeech, cannot reach the Linux kernel directly. Since the EFI Runtime Services are usually located below 4GB they offer a way into Linux on high memory EFI booting systems. Please see the video below for an example of how an attack may look like. […]

Full post:

http://blog.frizk.net/2017/01/attacking-uefi-and-linux.html

 

Longkit: a UEFI/BIOS/SMM rootkit (at ICISSP’17)

ICISSP 2017, in Portugal, has an upcoming UEFI/BIOS/SMM rootkit presentation that sounds interesting:

Longkit: A UEFI/BIOS Rootkit in the System Management Mode. ICISSP 2017
Julian Rauchberger, Robert Luh, Sebastian Schrittwieser.

The theoretical threat of malware inside the BIOS or UEFI of a computer has been known for almost a decade. It has been demonstrated multiple times that exploiting the System Management Mode (SMM), an operating mode implemented in the x86 architecture and executed with high privileges, is an extremely powerful method for implanting persistent malware on computer systems. However, previous BIOS/UEFI malware concepts described in the literature often focused on proof-of-concept implementations and did not have the goal of demonstrating the full range of threats stemming from SMM malware. In this paper, we present Longkit, a novel framework for BIOS/UEFI malware in the SMM. Longkit is universal in nature, meaning it is fully written in position-independent assembly and thus also runs on other BIOS/UEFI implementations with minimal modifications. The framework fully supports the 64-bit Intel architecture and is memory-layout aware, enabling targeted interaction with the operating system’s kernel. With Longkit we are able to demonstrate the full potential of malicious code in the SMM and provide researchers of novel SMM malware detection strategies with an easily adaptable rootkit to help evaluate their methods.

http://www.icissp.org/

https://www.jrz-target.at/2016/12/22/paper-accepted-at-icissp-2017/

Popcorn: another UEFI research OS

The list of UEFI research OSes has grown by one. Justin Miller has created Popcorn:

popcorn: A toy microkernel x64 UEFI OS: popcorn is a hobby OS for x64 UEFI environments to play with building a microkenerl architecture. It’s far from finished, or even being usable – for now, it’s a sandbox for me to explore the UEFI architecture, microkernels, and OS-related concepts that I want to play with.

https://github.com/justinian/popcorn

With Popcorn, that makes about 7 that I’ve seen (and I’m not watching academic news sources, where others may be hanging out). Here’s the other ones I’m aware of:

UEFI-OS

new EFI-based operating systems

 

 

Team Security on UEFI malware

https://twitter.com/security_de/status/817428032336052225

Team Security has an article on firmware malware, focusing on UEFI-centric malware, with many references to VirusTotal.com-based images.

[…]”We would like to specially thank Teddy Reed, developer of the UEFI firmware python parser, he has been instrumental in helping us overcome our ignorance about BIOS, UEFI, and its ecosystem.”

https://tsecurity.de/de/109335/IT-Security/Malware-Trojaner-Viren/Putting-the-spotlight-on-firmware-malware/

Leif on QEMU and USB host device pass-through

Leif has a new blog post on using UEFI with USB pass-through.

[…]”One thing that is unsurprising, but very cool and useful, is that this works well cross-architecture. So you can test that your drivers are truly portable by building (and testing) them for AARCH64, EBC and X64 without having to move around between physical machines.

http://blog.eciton.net/uefi/qemu-usb-passthrough.html

Checkout his previous blog post, on UEFI driver development, as well as older posts on Linaro/ARM/UEFI history.

 

Lenovo’s Think BIOS Config Tool

http://thinkdeploy.blogspot.com/2017/01/thinkpad-bios-to-uefi-conversion-using.html?spref=tw

https://docs.microsoft.com/en-us/sccm/osd/deploy-use/task-sequence-steps-to-manage-bios-to-uefi-conversion

http://thinkdeploy.blogspot.com/2016/08/the-think-bios-config-tool.html

Some related Lenovo BIOS tools:
https://support.lenovo.com/us/en/documents/ht100612
http://support.lenovo.com/us/en/downloads/ds014169
http://support.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-l-series-laptops/thinkpad-l420/downloads/ds019499

[I confess still not understanding what this “BIOS to UEFI” thing that Windows admin tools now have. Is it switching from Legacy to UEFI firmware then redoing the OS bits to handle that? Why are these boxes using Legacy  mode in the first place? Oh well.]

 

Yuriy to speak at REcon Brussels

 

https://recon.cx/2017/brussels/