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.



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.






Intel Sytem Debugger on debugging UEFI and SMM

I’m not sure if this is a new change, but I just noticed that the Intel System Debugger appears to have some fresh documentation:


Common Debugger Tasks
* Viewing and Modifying Registers
* Execution Trace
* Debugging UEFI BIOS
* Debugging Runtime Loaded Linux* OS Kernel Modules
* Debugging System Management Mode (SMM)
* Programming a Flash Memory


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.



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).



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.



“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 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.