APIC fail: Intel ‘Sunny Cove’ chips with SGX spill secrets
A group of computer scientists has identified an architectural error in certain recent Intel CPUs that can be abused to expose SGX enclave data like private encryption keys.
They call it ÆPIC Leak because it affects the memory-mapped registers of the local Advanced Programmable Interrupt Controller (APIC), which helps the CPU handle interrupt requests from various sources in order to facilitate multiprocessing.
Found by Pietro Borrello (Sapienza University of Rome), Andreas Kogler (Graz University of Technology), Martin Schwarzl (Graz), Moritz Lipp (Amazon Web Services), Daniel Gruss (Graz), and Michael Schwarz (CISPA Helmholtz Center for Information Security), the flaw is described in a paper [PDF] titled, “ÆPIC Leak: Architecturally Leaking Uninitialized Data from the Microarchitecture.”
“We discover ÆPIC Leak, the first architectural CPU bug that leaks stale data from the microarchitecture without using a side channel,” the authors explain in their paper, which was provided to The Register.
The bug affects recent Intel CPUs based on the company’s Sunny Cove microarchitecture, the authors say. This includes: Intel’s 10th generation Ice Lake CPUs; its current 3rd generation Xeon scalable server CPUs (Ice Lake SP); and, it is claimed, new 12th generation Alder Lake CPUs (Golden Cove).
But there’s some disagreement about this: Intel says Alder Lake isn’t affected because it doesn’t support SGX, but allows that other CPUs not identified by the researchers are affected (see below).
ÆPIC Leak is not a transient execution attack like Meltdown that relies on a side-channel to infer sensitive data. Rather it’s the result of a chip architecture flaw along the lines of the Pentium FDIV bug or the Pentium F00F bug.
The authors liken the bug to an uninitialized memory read in the CPU itself. They scanned the I/O address space on Sunny Cove-based Intel CPUs and found that the memory-mapped registers of the local APIC are not cleanly initialized. Consequently, reading these registers returns stale data of recent memory loads and stores that went from the L2 to the L3 cache or vice versa.
Fortunately, accessing the APIC MIMO requires admin or root privileges, so for most systems ÆPIC Leak isn’t an issue. In a virtualized environment, for example, hypervisors do not expose direct access to the host local APIC. So a malicious VM could not exploit the bug to leak data.
However, on systems using Intel SGX – Software Guard Extensions, hardware-based memory encryption for creating secure, isolated environments – the architecture flaw becomes meaningful. The researchers devised two techniques – Cache Line Freezing and Enclave Shaking – that they were able to use to obtain AES-NI keys and RSA keys from Intel’s IPP library and the Intel SGX sealing and remote attestation keys.
Intel in January announced that it is deprecating SGX – already battered by several attacks – for its client CPUs. But the technology remains in place for server CPUs like third-generation Xeons. If ÆPIC Leak is not addressed, the researchers say, the bug poses “a significant threat to enclave security.”
The vulnerability was disclosed to Intel on December 8, 2021, and was acknowledged on December 22, 2021, and assigned CVE-2022-21233. As short-term mitigations, the researchers suggest disabling APIC MMIO or avoiding SGX; they allow that a microcode/firmware update could work though they recommend the improper initialization be addressed in hardware.
The research paper says proof-of-concept code will be made available at the URL https://github.com/IAIK/AEPIC.
Intel on Tuesday plans to release 27 security advisories addressing 59 vulnerabilities. One of the advisories deals with ÆPIC Leak.
“INTEL-SA-00657 addresses an issue discovered by researchers from TU Graz they refer to as ÆPIC Leak,” said Jerry Bryant, senior director of security communications and incident response for Intel in a statement provided to The Register. “Those using Intel SGX should review the advisory to understand the mitigations we have released as well as our Stale Data Read from xAPIC technical paper.”
Intel’s list of affected CPUs extends beyond the set explored by the researchers. It includes: Ice Lake Xeon-SP, Ice Lake D, Gemini Lake, Ice Lake U,Y, and Rocket Lake.
“Researchers have demonstrated attacks against Intel SGX enclaves, where stale data may be exposed by an attacker who controls the OS and can read from the legacy xAPIC,” a company spokesperson said in an email. “On some processors, incorrectly aligned reads from addresses in the xAPIC MMIO page could return stale data, which may correspond to data previously read by the same processor core that is reading the xAPIC page.”
“Intel recommends that operating systems (OSes) and virtual machine monitors (VMMs) enable x2APIC mode, which disables the xAPIC MMIO page and instead exposes APIC registers through model specific registers (MSRs), which mitigates this issue in affected products. APIC virtualization is not affected; this behavior only applies to access to the physical xAPIC MMIO page.”
Intel continues to recommend the use of Intel SGX and intends to provide a revised Intel SGX Software Development Kit (SDK) for Windows and Linux to help reduce the chance that enclave data might be inferred.
In their paper, the authors explore how both architectural and transient-execution vulnerabilities share a common underlying type of vulnerability, or Common Weakness Enumeration.
In this instance, CWE-665: Improper Initialization made the transient-execution vulnerabilities CrossTalk and Medusa possible and led to the architectural flaw behind ÆPIC Leak.
Daniel Gruss, a co-author of the paper and assistant professor in the secure systems group at the Graz University of Technology, told The Register in an email that he expects “bugs from further different CWE classes to be found in hardware in the future.”
Gruss, as it happens, is among another set of computer scientists who have identified a side-channel attack on scheduler queues, which schedule the instructions to be executed in superscalar CPUs.
The attack is described in a paper [PDF] titled, “SQUIP: Exploiting the Scheduler Queue Contention Side Channel.” Its authors include: Stefan Gast (Lamarr Security Research & Graz University of Technology), Jonas Juffinger (Lamarr Security Research & Graz University of Technology), Martin Schwarzl (Graz University of Technology), Gururaj Saileshwar (Georgia Institute of Technology), Andreas Kogler (Graz University of Technology), Simone Franza (Graz University of Technology), Markus Kostl (Graz University of Technology), and Daniel Gruss (Graz University of Technology).
Intel chips are unaffected by the SQUIP attack because they rely on a single scheduler queue, the SQUIP paper explains. However, AMD Zen 1 (not mentioned by the researchers but confirmed by AMD), Zen 2, and Zen 3 microarchitectures implement separate scheduler queues per execution unit, so contention between different units can be exploited to glean information.
The attack – which can determine an RSA-4096 key in about 38 minutes – assumes the attacker and target are co-located on different SMT threads of the same physical core, but are from different security domains. In short, it’s relevant mainly for cloud tenants relying on shared hardware.
“An attacker running on the same host and CPU core as you, could spy on which types of instructions you are executing due to the split-scheduler design on AMD CPUs,” explained Gruss. “Apple’s M1 (probably also M2) follows the same design but is not affected yet as they haven’t introduced SMT in their CPUs yet.”
A spokesperson for AMD said the vulnerability has been designated medium severity and is being referred to as “AMD-SB-1039: Execution Unit Scheduler Contention Side-Channel vulnerability on AMD Processors.”
AMD’s 1st, 2nd, 3rd Gen Zen processors are affected.
“AMD recommends software developers employ existing best practices [1][2], including constant-time algorithms and avoiding secret-dependent control flows where appropriate to help mitigate this potential vulnerability,” the company spokesperson told The Register. ®
READ MORE HERE