Für alle die nach per Praxis fragen, hier ist das Paper:
https://cacheoutattack.com/CacheOut.pdf
"To demonstrate the practical risk that CacheOut poses
even in the case where
HyperThreading is disabled, we developed a proof of concept attack wherein an
unprivileged user process leaks confidential data from another process. Moreover, in our example we demonstrate the feasibility of address selection, which
allows the attacker to choose what locations she wants to read in the victim’s address space. This capability allows us to lift the known-prefix or known-suffix restriction of [47], where in order to leak the data that attack must know some prefix or suffix of it. Experimental Setup. We run the attack presented in this section on two machines. The first is equipped with an Intel i7-8665 CPU (Whiskey Lake), running Linux Ubuntu 18.04.3 LTS with a 5.0.0-37 generic kernel. Our second machine is equipped with an Intel Core i9-9900K (Coffee Lake Refresh, Stepping 13) running Linux Ubuntu 18.04.1 LTS with a 5.3.0-26 generic kernel. The former machines uses microcode version 0xca, while the latter uses 0xb8. Leaking from OpenSSL AES. Our cross-process attack aims to leak the AES key as well as the plaintext message that results from the victim decrypting AES. To that aim, we constructed a victim process that repeatedly decrypts an encrypted message, followed by issuing the sched_yield() system call. The attacking process runs sequentially on the same virtual core, and repeatedly calls sched_yield() to allow the victim to run and decrypt the ciphertext. After the victim finishes running, the attacker evicts the L1-D cache set of interest with the goal of leaking interesting information from the victim process into the line fill buffer. Then the attacker uses TAA to sample the AES key as well as the decrypted message from the line fill buffer. Figure 6 illustrates this process. Finally, even though we artificially instrumented the victim process to yield the CPU to simplify the synchronization problem, [14] demonstrate that this is not a fundamental limitation and can be overcome with an attack on the Linux scheduler. Experimental Results. Compared to previous techniques [42, 47], our attack benefits from CacheOut’s cache line selection capabilities. By targeting specific cache lines to leak from, our attack classifies plaintext bytes with 96.8% accuracy and AES keys with 90.0% accuracy, taking 15 seconds on average to recover a single 64 bytes cache line."
Weiterlesen lohnt sich!
Absätze:
6 Attacks on Linux Kernel
6.2 Defeating Kernel Stack Canaries
7 Breaking Virtualization
8 Breaching SGX Enclaves (SGX = Software Guard Extensions)
und zu guter letzt woran geschraubt werden muss:
9 Mitigations We will now discuss various ways to mitigate CacheOut: disabling Intel Hyper-Threading, flushing the L1-D cache, and disabling TSX. Disabling Intel Hyper-Threading. Similar to MDS, CacheOut can be used to leak across Intel Hyper Threads. As synchronizing different threads is not straight-forward, one way of mitigating the cross-thread leakage is to disable Intel Hyper-Threading for workloads where security is more important. Unfortunately, disabling Intel Hyper-Threading does not cover the case where the attacker and the victim run on the same CPU thread. Flushing the L1-D cache. As discussed in Section 4.3, flushing the L1-D cache appears to be an effective mitigation against CacheOut. To offer a complete mitigation on machines affected by both MDS and CacheOut, the kernel would have to issue an MSR_IA32_FLUSH_CMD followed by verw for each context switch, and for machines that are not affected by MDS, issuing just the MSR_IA32_FLUSH_CMD would be sufficient. Unfortunately, flushing the L1-D cache adds significant overhead and only covers the case without Intel Hyper-Threading. Disabling TSX. To address TSX Asynchronous Abort (TAA) [20] on the newest platforms released after Coffee Lake Refresh (i.e., released after Q4 of 2018), Intel released a series of microcode updates between September and December 2019 that disable transactional memory. These microcode updates introduce MSR_IA32_TSX_CTRL (MSR 0x122), where setting the first bit in the MSR disables TSX, and setting the second bit disables CPUID enumeration for TSX capability. Concurrently to our work, after the disclosure of TAA, operating system vendors started disabling TSX through MSR_- IA32_TSX_CTRL by default on all Intel machines released after Q4 of 2018. For the majority of Intel machines (i.e., all machines released before 2018-Q4), Intel started rolling out microcode updates to address CPU errata regarding TSX [22]. These microcode updates introduce MSR_TSX_FORCE_ABORT (MSR 0x10f), where setting the first bit in the MSR forces any TSX transaction to always abort. However, as of writing, this behavior is not enabled by default, leaving these machines exposed to CacheOut. Given that TSX is not widely used at the time of writing, we thus recommend that TSX be disabled by default on these machines as well. Microcode Updates. Intel’s security advisory [23] indicates that CacheOut (called L1Des in Intel’s terminology) will be mitigated via additional microcode updates. We recommend that these be Installed by users of affected systems.
Finanziert wurde die Forschung übrigens von DARPA und Air Force Research Laboratory
ich weiß schon warum ich diesen Laden in Zukunft meide. 
