UEFI Firmware Rootkits: Myths and Reality: video online




CVE-2017-3753: AMI Lenovo UEFI SMM vulnerability

Lenovo says scope of AMI issue is “Industry-Wide”, which implies that other Intel/AMI-based OEMs may also have this issue, not just Lenovo.

BIOS SMI Handler Input Validation Failures
CVE Identifier: CVE-2017-3753

Lenovo Security Advisory: LEN-14695
Severity: High
Scope of Impact: Industry-Wide
Last Modified: 08/09/2017

Potential Impact: Execution of code in SMM by an attacker with local administrative access

A vulnerability has been identified in some Lenovo products that use UEFI code developed by AMI. With this vulnerability, conditions exist where an attacker with administrative privileges or physical access to a system may be able to run specially crafted code that can allow them to bypass system protections such as Device Guard and Hyper-V. AMI has supplied a fix for this vulnerability to Lenovo. Users should update the BIOS on affected systems to the latest available version to address this issue.

Security-conscious users should consider the following mitigation steps if an immediate BIOS update is not possible to protect themselves to the fullest extent with the understanding that they DO NOT fix or fully protect against an exploit of this vulnerability:

* Enable Secure Boot on your system
* Disable the boot to UEFI shell
* Disable boot from any source but the primary internal hard drive
* Set a BIOS setup password, so Secure Boot cannot be disabled and the boot to the UEFI shell cannot be re-enabled
* Operate as an unprivileged (non-administrator)

AFAICT nothing on the AMI site on this.


Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.


[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt



UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:


The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:


Dmytro on PCI-E/SMM vulnerability

Dmytro has an interesting 6-part twitter post on PCI-e security:


Intel Excite project

There is a new document out from Intel that describes their Excite project. No URL to source code, AFAICT.

Finding BIOS Vulnerabilities with Symbolic Execution and Virtual Platforms
By Engblom, Jakob (Intel), Added June 6, 2017
Finding BIOS Vulnerabilities With Excite
Finding vulnerabilities in code is part of the constant security game between attackers and defenders. An attacker only needs to find one opening to be successful, while a defender needs to search for and plug all or at least most of the holes in a system. Thus, a defender needs more effective tools than the attacker to come out ahead.[…]




Intel NUC SMM exploit

Intel® Branded NUC’s Vulnerable to SMM exploit
Intel ID:      INTEL-SA-00068
Product family:      Intel® NUC Kits
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important
Original release:      May 02, 2017
Last revised:      May 02, 2017

Intel is releasing updated BIOS firmware for a privilege escalation issue. This issue affects Intel® NUC Kits listed in the Model Number section below. 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 vulnerable BIOS to execute arbitrary code outside of SMRAM while system is running in System management mode (SMM), potentially compromising the platform. Intel products that are listed below should apply the update. Intel highly recommends updating the BIOS of all Intel® NUC’s to the recommended BIOS or later listed in the table of affected products. Intel would like to thank Security Researcher Dmytro Oleksiuk for discovering and reporting this issue.