arrow_upward

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CacheOut - Another hole in Intels universum
#1
CacheOut - "A new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries."


Another security issue has been found in the design of Intels CPUs reaching back to productions from 2018. As the heading says this security hole allows to leak data across many different security measures made by Intel to prevent data leaks. Compared to the old MDS issue this new issue is way more serious because an attack can decide what data he wants to be leaked while MDS only allowed data to be leaked that was loaded into the CPU and was only leakable while it was processed by the CPU.

What is affected? Well, all products from NOW going back to 2018. A list is available here: https://software.intel.com/security-soft...n-sampling

CacheOut page: https://cacheoutattack.com/

Is AMD affected? No, AMD is not affected. Only Intel is affected because only Intel has the TSX Asynchronous Abort (TAA) feature on their CPUs.

Mitigation for the issue is available. Probably at the cost of more perforamnce (not confirmed, yet).
[Image: zHHqO5Q.png]
#2
I've just skimmed through the research paper -CacheOut: Leaking Data on Intel CPUs via Cache Evictions-, rather interesting read!

It turns out that Intel didn't do a good job with its ad-hoc buffer over-write countermeasures against MDS-type attacks, which has led to what's now called CacheOut (or L1DES in Intel’s terminology).

The paper's authors where trying to answer the following questions:
Quote:Are buffer overwrites sufficient to block MDS-type attacks? In particular, can an adversary exploit the still leaky CPU buffers in Intel CPUs despite their content being properly overwritten?
And
Quote:Is it possible for the attacker to leak information across arbitrary address spaces, while somehow retaining the capability of selecting which data to leak? If so, how can such attack be implemented in the presence of existing MDS countermeasures?
And
Quote:Is HyperThreading essential for mounting MDS type attacks? How can an adversary recover data without the use of Hyper-Threading in the presence of proper buffer overwrite between security domains?

Their findings and I paraphrase them:
  • They presented CacheOut, which they describe as "the first speculative execution attack that can leak across arbitrary address spaces while still retaining fine grained control over what data to leak. Moreover, unlike other MDS-type attacks, CacheOut cannot be mitigated by simply flushing internal CPU buffers between context switches, even when hyperthreading is disabled."
  • They demonstrate the effectiveness of CacheOut in violating process isolation by recovering AES keys and plaintexts from an OpenSSL-based victim.
  • They demonstrate practical exploits for completely derandomizing Linux’s kernel ASLR, and for recovering secret stack canaries from the Linux kernel (this one will certainly bug Linus Torvald.)
  • They demonstrate how CacheOut is effective for violating isolation between two virtual machines running on the same physical core. (This one is for the Cloud industry.)
  • They breach SGX’s confidentiality guarantees by reading out the contents of a secure enclave.
  • They demonstrate that some of the latest Meltdown-resistant Intel CPUs are still vulnerable, despite all of the most recent patches and mitigations.
  • They discuss why current speculative attack mitigations are insufficient, and offer suggestions on what countermeasures would effectively mitigate CacheOut.

Intel was notified back in October 2019 with the issue, which they acknowledged it as L1 Data Eviction Sampling (L1DES) with a CVSS score of 6.5 (medium). The issue has been assigned CVE-2020-0549.

The current status as presented by the authors is that
Quote:(...) Intel recently published microcode updates that enable turning off Transactional Memory Extension (TSX) on its CPUs. These are also effective against CacheOut and we recommend that TSX be turned off across all current Intel platforms. Finally, Intel’s security advisory [23] indicates that microcode updates mitigating CacheOut (called L1DES in Intel’s terminology) will be published with the public disclosure of our results. We recommend these be installed on affected Intel platforms.

This post was meant to entice you all to take a look at the research paper. For the what to do about this for the common mortals like us, the web site referenced in the OP answers most of the relevant questions in its 'Questions & Answers' section.
https://cacheoutattack.com/

--------------------------
Used Exotic Acronyms:
MDS: Microarchitectural Data Sampling
L1DES: L1 Data Eviction Sampling.
ASLR: Address Space Layout Randomization
SGX: Intel’s Secure Guard Extensions
TSX: Transactional Memory Extension
VirMach's Buffalo_VPS-9 Holder (Dec. 20 - July 21)
microLXC's Container Holder (july 20 - ?)
VirMach's Phoenix_VPS-9 Holder (Apr. 20 - June 20)
NanoKVM's NAT-VPS Holder (jan. 20 - ?)


person_pin_circle Users browsing this thread: 1 Guest(s)
Sponsors: VirMach - Host4Fun - CubeData - Evolution-Host - HostDare - Hyper Expert - Shadow Hosting - Bladenode - Hostlease - RackNerd - ReadyDedis - Limitless Hosting