[fChk]

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:

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

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

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

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