Intel 'Sunny Cove' SGX Vulnerability Discovered

vulnerability
(Image credit: Shutterstock)

Originally meant to enable secure execution in an isolated environment, Intel's Software Guard Extensions (SGX) memory encryption technology could do more harm than good. It turns out, processors featuring Intel's Sunny Cove microarchitecture may expose data located in the memory-mapped registers of the local Advanced Programmable Interrupt Controller (APIC), reports The Register

The registers are reportedly not initialized cleanly and therefore reading them exposes stale date of recent sample data transferred between the L2 and last-level cache, including SGX enclave data, from the super queue. Researchers call the vulnerability ÆPIC Leak (aka CWE-665: Improper Initialization) and claim that the bug has hardware origins. 

Intel claims that the affected processors include all chips based on the Sunny Cove/Cypress Cove microarchitectures, which covers 10th Generation Core 'Tiger Lake' and 'Rocket Lake', 3rd Generation Xeon Scalable 'Ice Lake-SP', and Xeon D-1700/2700 products. In addition, Atom, Celeron, and Pentium system-on-chips featuring the Gemini Lake microarchitecture are vulnerable to the same kind of attack. 

Meanwhile, to access data from APIC registers, perpetrators need to have admin or root privileges. Which makes the use of this weakness slightly harder to exploit (but not impossible). In virtualized environments hypervisors do not allow virtual machines access to APIC registers. 

Intel admits the problems with its SGX technology and has issued a set of recommendations on how to avoid potential problems with the vulnerability. Meanwhile, the researchers who discovered the bug late last year offer their own fix for the problem. 

Interestingly, some of the investigators who exposed the ÆPIC Leak bug also recently identified the first side-channel attack on scheduler queues. The vulnerability affects all of AMD's existing Ryzen processors featuring Zen 1/2/3 microarchitectures. To exploit the weakness and get access to data processed by the same CPU core, perpetrators need to run malicious code on that CPU core first, which is not particularly easy.  

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

AMD reportedly confirmed the problem — currently called AMD-SB-1039: Execution Unit Scheduler Contention Side-Channel vulnerability on AMD Processors — and said that the company considers it a 'medium severity' threat.

Anton Shilov
Contributing Writer

Anton Shilov is a contributing writer at Tom’s Hardware. Over the past couple of decades, he has covered everything from CPUs and GPUs to supercomputers and from modern process technologies and latest fab tools to high-tech industry trends.

  • edzieba
    Some important features of this bug:
    Only affects SGX enclaves (i.e. a nonissue for desktops and laptops)
    Can only be exploited if you already have root permissions (i.e. for any desktop/laptop and most servers, you're already PWNed pretty hard before this is even an option)
    Not possible from inside a VM, requires direct access to physical memory (why root is required)
    Only Sunny Cove cores are affected, other chips with other SGX versions (or that do not have SGX available) are not affected. In practice, this means Ice Lake SP is the only affected platform that is likely to even be using SGX enclaves.
    Using x2APIC rather than the legacy xAPIC mode elimiantes the vulnerabiltiy for no performance impact
    tl;dr: Are you running an Ice Lake SP server, using SGX enclaves, and using xAPIC rather than x2APIC, and an adversary has root access outside of a VM? If so, you are vulnerable and need to switch to using x2APIC. If not, then you're fine.
    Reply
  • rluker5
    Meanwhile, as a footnote: "The vulnerability affects all of AMD's existing Ryzen processors featuring Zen 1/2/3 microarchitectures. To exploit the weakness and get access to data processed by the same CPU core, perpetrators need to run malicious code on that CPU core first, which is not particularly easy. "
    AMD gets what seems to be a worse problem than the one Intel had when the old "disable hyperthreading" Foreshadow bug came out. That one is long fixed, but this new AMD one presents every bit as consequential of a risk (really pretty close to negligible, but Intel's was moreso).

    And the only fix is to disable SMT, but AMD just recommends you ignore the bug and do best practices because security exploits are hard to do.
    Reply