SMM disabling and verification techniques

3mdeb points out that there is a patent by Intel with information focused on disabling Intel SMM.

Don’t click on this link if you’re an engineer and are not allowed to view patent information.

 

https://patents.google.com/patent/US20170168844

EPA-RIMM: A Framework for Dynamic SMM-based Runtime Integrity Measurement

EPA-RIMM: A Framework for Dynamic SMM-based Runtime Integrity Measurement
Brian Delgado, Karen L. Karavanic
(Submitted on 9 May 2018)

Runtime integrity measurements identify unexpected changes in operating systems and hypervisors during operation, enabling early detection of persistent threats. System Management Mode, a privileged x86 CPU mode, has the potential to effectively perform such rootkit detection. Previously proposed SMM-based approaches demonstrated effective detection capabilities, but at a cost of performance degradation and software side effects. In this paper we introduce our solution to these problems, an SMM-based Extensible, Performance Aware Runtime Integrity Measurement Mechanism called EPA-RIMM. The EPA-RIMM architecture features a performance-sensitive design that decomposes large integrity measurements and schedules them to control perturbation and side effects. EPA-RIMM’s decomposition of long-running measurements into shorter tasks, extensibility, and use of SMM complicates the efforts of malicious code to detect or avoid the integrity measurements. Using a Minnowboard-based prototype, we demonstrate its detection capabilities and performance impacts. Early results are promising, and suggest that EPA-RIMM will meet production-level performance constraints while continuously monitoring key OS and hypervisor data structures for signs of attack.

https://arxiv.org/abs/1805.03755

http://web.cecs.pdx.edu/~karavan/research/SMM.html

INTEL-SA-00110: BIOS SW SMI Call-Out EoP

Intel® NUC BIOS SW SMI Call-Out

Intel ID: INTEL-SA-00110
Product family: Intel® NUC Kits
Impact of vulnerability: Elevation of Privilege
Severity rating: Important
Original release: Apr 17, 2018
Last revised: Apr 17, 2018
Summary:

This update will improve the security of system firmware for the below listed Intel NUC models. Intel has identified a potential vulnerability in Intel NUC kits with insufficient input validation in system firmware that potentially allows a local attacker to elevate privileges to System Management Mode (SMM). Intel highly recommends that users update to the latest firmware version (see table above).

Intel would like to thank Embedi for reporting this issue and working with us on coordinated disclosure.

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

 

Aurora: Providing Trusted System Services for Enclaves On an Untrusted System

Aurora: Providing Trusted System Services for Enclaves On an Untrusted System
Hongliang Liang, Mingyu Li, Qiong Zhang, Yue Yu, Lin Jiang, Yixiu Chen
(Submitted on 10 Feb 2018)

Intel SGX provisions shielded executions for security-sensitive computation, but lacks support for trusted system services (TSS), such as clock, network and filesystem. This makes \textit{enclaves} vulnerable to Iago attacks~\cite{DBLP:conf/asplos/CheckowayS13} in the face of a powerful malicious system. To mitigate this problem, we present Aurora, a novel architecture that provides TSSes via a secure channel between enclaves and devices on top of an untrusted system, and implement two types of TSSes, i.e. clock and end-to-end network. We evaluate our solution by porting SQLite and OpenSSL into Aurora, experimental results show that SQLite benefits from a \textit{microsecond} accuracy trusted clock and OpenSSL gains end-to-end secure network with about 1ms overhead.

https://arxiv.org/abs/1802.03530

SMM rootkits: a new breed of malware

The below video was uploaded recently. The previous talk was from a few years ago. I’m unclear if this video is new or from a few years ago…

The emergence of hardware virtualization technology has led to the development of OS independent malware such as the Virtual Machine based rootkits (VMBRs). In this paper, we draw attention to a different but related threat that exists on many commodity systems in operation today: The System Management Mode based rootkit (SMBR). System Management Mode (SMM) is a relatively obscure mode on Intel processors used for low-level hardware control. It has its own private memory space and execution environment which is generally invisible to code running outside (e.g., the Operating System). Furthermore, SMM code is completely non-preemptible, lacks any concept of privilege level, and is immune to memory protection mechanisms. These features make it a potentially attractive home for stealthy rootkits. In this paper, we present our development of a proof of concept SMM rootkit. In it, we explore the potential of System Management Mode for malicious use by implementing a chipset level keylogger and a network backdoor capable of directly interacting with the network card to send logged keystrokes to a remote machine via UDP. The rootkit hides its memory footprint and requires no changes to the existing Operating System. It is compared and contrasted with VMBRs. Finally, techniques to defend against these threats are explored. By taking an offensive perspective we hope to help security researchers better understand the depth and scope of the problems posed by an emerging class of OS independent malware.

https://dl.acm.org/citation.cfm?id=1460892

http://clearhatconsulting.com/index.php/papers/

https://www.scribd.com/document/348281470/System-Management-Mode-Rootkits-by-Shawn-Embleton-and-Sherri-Sparks

 

Embedi SMM_USBRT_POC: CVE-2017-5721 UsbRt SMM EoP

CVE-2017-5721 Proof-of-Concept

UsbRt SMM Privilege Elevation

This is a Proof-of-Concept code that demonstrates the exploitation of the CVE-2017-5721 vulnerability. This PoC causes a system to be completely stuck because of Machine Check Exception occurred.

All you need is CHIPSEC Framework installed. And don’t forget to put GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash acpi=off” in /etc/default/grub if you have Intel device.

https://github.com/embedi/smm_usbrt_poc

HP Labs: Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the SMM

Co-processor-based Behavior Monitoring: Application to the Detection of Attacks Against the System Management Mode
Ronny Chevalier, Maugan Villatel, David Plaquin, Guillaume Hiet
HP Labs
Highly privileged software, such as firmware, is an attractive target for attackers. Thus, BIOS vendors use cryptographic signatures to ensure firmware integrity at boot time. Nevertheless, such protection does not prevent an attacker from exploiting vulnerabilities at runtime. To detect such attacks, we propose an event-based behavior monitoring approach that links to an isolated co-processor. We instrument the code executed on the main CPU to send information about its behavior to the monitor. This information helps to solve the semantic gap issue. Our approach does not depend on a specific model of the behavior nor a specific target. We apply this approach to detect system management mode (SMM), a highly privileged x86 executable mode executing firmware code at runtime. We model the behavior of SMM using CPU registers (CR3 and SMBASE). We have two open-source firmware implementations: EDK II and coreboot. We evaluate the ability to detect and detect the effects of ARM Cortex A5 co-processor. The results show that our solution detects intrusions from the state of the art, without any false positives, while remaining acceptable in terms of performance overhead in the context of the SMM (ie, less than the 150 μs threshold defined by Intel).

https://hal.inria.fr/hal-01634566/

Fall UEFI Plugfest agenda

The Fall UEFI Plugfest is happening, a week of interop testing with UEFI vendors, along with some presentations. The presentation abstracts are below, see the full itenary for speaker bios.

http://www.uefi.org/events/upcoming

http://www.uefi.org/sites/default/files/resources/Agenda%20and%20Session%20Abstracts%20-%20Final_Oct%2024%202017.pdf

“Last Mile” Barriers to Removing Legacy BIOS (Intel)
While UEFI has become a dominant standard since its introduction in 2005, many use cases still rely on compatibility with PC/AT Legacy BIOS. These legacy corner cases are a barrier to completing the transition to modern firmware standards. Intel has identified maintaining compatibility as an issue for platform security and validation costs, and plans to eliminate legacy BIOS elements in our 2020 data center platforms. This session discusses “last mile” gaps for 16-bit compatibility and identifies UEFI capabilities that the industry can promote as alternatives, including HTTPS Boot, OS Recovery, and Signed Capsule Update.

UEFI Firmware – Security Concerns and Best Practices (Phoenix)
(no Abstract)

Strategies for Stronger Software SMI Security in UEFI Firmware (Insyde)
Avoid design errors and software coding pitfalls when implementing SMI handlers. Device manufacturers customize UEFI firmware using new runtime interfaces that are implemented using software SMIs. Heavy customization, tight deadlines and poor code implementation can accidentally allow malware to abuse the power of SMM. This session focuses on four common software SMI vulnerabilities and how to change your UEFI firmware and applications to avoid them.

Advances of UEFI Technologies in ARM Systems (ARM)
This session will discuss the ARM-related interfaces defined in the latest UEFI and ACPI specifications, the requirements of the UEFI and ACPI interfaces for the SBBR Specification, and the use of UEFI SCT and FWTS in the SBBR compliance test. Also, discussed will be the required UEFI interfaces for the embedded space when the separation of the device and OS development is desired.

Introduction to the Self-Certification Test (SCT) in UEFI World (Canonical and Intel)
The UEFI Test Working Group (UTWG) endorses two test suites: Firmware Test Suite (FWTS) and the UEFI Self-Certification Test (SCT). FWTS is focused on validating Linux compatibility, and is endorsed by UTWG for ACPI validation. The UEFI SCT is designed to validate firmware and driver behavior per the UEFI Specification. This session demonstrates the operation of both tools, and discusses how they use open source models to improve test quality.

Firmware Test Suite Introduction: Uses, Development, Contribution and GPL (Canonical)
Firmware Test Suite (FWTS) is the recommended ACPI 6.1 Self-Certification Test (SCT). This command line tool is easy to use and provides explanatory and informative. Its open-source nature allows developers to add new tests easily, and many code examples such as ACPI, UEFI and SMBIOS are available for references. Code contribution are appreciated and technical discussion and code reviews on the mailing list are answered by an active community. As licensed by GPL, FWTS ensures it is available and suitable to everyone who wants to use it publicly and privately.

NFC and UEFI (AMI)
NFC is a technology that has permeated many aspects of everyday life. Using NFC, you can now pay with your phone or enter secure building areas. However, the UEFI specification lacks any implementation of NFC. AMI will cover a proposed solution for NFC implementation in UEFI, how to best fit NFC into the UEFI specification, and potential use cases.

Edk2 Platforms Overview (Linaro)
For a couple of years now, the Linaro OpenPlatformPkg repository has been used to collate a number of (at least partially) open source EDK2 platform ports. However, with a now properly defined process for the TianoCore edk2-platforms and edk2-non-osi repositories, these platforms are now moving over there and OpenPlatformPkg. This session will discuss the process, the current state of things and the practicalities of working with edk2-platforms.

UEFI Manageability and REST Services (HPE and Intel)
With the increase in platform firmware complexity and capabilities, there is an increased need to standard firmware manageability is increasing. The UEFI 2.7 Specification defines REST services to provide secure solutions for managing modern platforms. This session describes enterprise configuration scenarios, discusses implementation gaps in the UEFI specification, and proposes enhancements related to vendor-specific REST services.

Scotch: Combining SGX and SMM to Monitor Cloud Resource Usage

First Online: 12 October 2017
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10453)

The growing reliance on cloud-based services has led to increased focus on cloud security. Cloud providers must deal with concerns from customers about the overall security of their cloud infrastructures. In particular, an increasing number of cloud attacks target resource allocation in cloud environments. For example, vulnerabilities in a hypervisor scheduler can be exploited by attackers to effectively steal CPU time from other benign guests on the same hypervisor. In this paper, we present Scotch, a system for transparent and accurate resource consumption accounting in a hypervisor. By combining x86-based System Management Mode with Intel Software Guard Extensions, we can ensure the integrity of our accounting information, even when the hypervisor has been compromised by an escaped malicious guest. We show that we can account for resources at every task switch and I/O interrupt, giving us richly detailed resource consumption information for each guest running on the hypervisor. We show that using our system incurs small but manageable overhead—roughly 1 μ
s every task switch or I/O interrupt. We further discuss performance improvements that can be made for our proposed system by performing accounting at random intervals. Finally, we discuss the viability of this approach against multiple types of cloud-based resource attacks.

https://link.springer.com/chapter/10.1007/978-3-319-66332-6_18

UEFI Firmware Rootkits: Myths and Reality: video online

https://github.com/REhints/Publications/blob/master/Conferences/BHASIA%202017/BHASIA_2017_final.pdf

https://firmwaresecurity.com/2017/04/02/uefi-firmware-rootkits-myths-and-reality/
https://firmwaresecurity.com/2017/02/09/black-hat-asia-the-uefi-firmware-rootkits-myths-and-reality/

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)

https://nvd.nist.gov/vuln/detail/CVE-2017-3753
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3753
https://support.lenovo.com/us/en/product_security/len-14695
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.

https://github.com/gencymex/smmtestbuildscript

[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:

http://wiki.qemu.org/ChangeLog/2.9

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:
https://getfedora.org/
https://en.wikipedia.org/wiki/System_Management_Mode

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.[…]

 

https://software.intel.com/en-us/blogs/2017/06/06/finding-bios-vulnerabilities-with-excite

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.

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

Shell script for Laszlo’s SMM test environment article

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

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

[2] https://github.com/gencymex/smmtestbuildscript

https://github.com/gencymex/smmtestbuildscript/blob/master/smmtesthost.sh

scan_thinkpwn: searches for ThinkPwn vulnerability

THINKPWN SCANNER: This program is used to scan UEFI drivers extracted from firmware image for ThinkPwn vulnerability in vendor/model agnostic way.
AUTHORS:
@d_olex (aka Cr4sh) — initial Vivisect based version of the program;

@trufae (aka pankake) — radare2 based version (this one);

Read the source code for more user docs, including a detailed source comment about how the code works.

https://github.com/Cr4sh/ThinkPwn/blob/master/scan_thinkpwn.py

More info:
https://github.com/Cr4sh/ThinkPwn
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html