https://www.tomshardware.com/uk/new...ities-in-cascade-lake-chips-and-a-new-jcc-bug
The organizations also said in their TL;DR that "an attacker can mount a RIDL attack despite the in-silicon mitigations/microcode patches published in May 2019 being in place."
From
https://mdsattacks.com/
In particular, at the request of Intel, we withheld the following details on the original RIDL/MDS disclosure date:
- TSX Asynchronous Abort (TAA). Intel's TSX hardware feature can be used to efficiently mount a RIDL attack even on allegedly non-vulnerable CPUs (with hardware mitigations).
- Alignment faults. These can be used to trigger an exception, giving an attacker yet another way of leaking data. This attack vector seems to be fixed in the latest generation of Intel CPUs.
- Flawed MDS mitigation. The initial mitigations against MDS clear the buffers by writing stale, potentially sensitive, data into these buffers, allowing an attacker to leak information despite mitigations being enabled.
- The RIDL test suite. We can now release the RIDL test suite at https://github.com/vusec/ridl.
Impact
TL;DR: an attacker can mount a RIDL attack despite the in-silicon mitigations/microcode patches published in May 2019 being in place.
In particular,
TSX Asynchronous Abort (TAA) allowed us to mount a practical RIDL exploit (as already shown in
/etc/shadow leak presented in the RIDL paper) even on systems with in-silicon/microcode MDS mitigations enabled. Moreover, one of our brilliant Master students (
Jonas Theis) used TAA to optimize our initial password-disclosing exploit to run in just 30 seconds (
!!), rather than the initial 24 hours (as seen in the video below).
RIDL-TAA leaking full root password hash in seconds
On Nov 12, 2019, TAA and the other scheduled RIDL issues are disclosed. Unfortunately, we believe that, given the piecemeal (variant-by-variant) mitigation approach pursued by Intel, RIDL-class vulnerabilities won't disappear any time soon.
We are particularly worried about Intel's mitigation plan being PoC(Proof of Concept)-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, leaving the public with a false sense of security. Slapping a year-long embargo after another (many news cycles apart) and keeping vulnerabilities (too) many people are aware of from the public for a long time is still a viable strategy.
https://zombieloadattack.com/
Update: New Variant of ZombieLoad enables attacks on MDS-resistant CPUs
CVE-2018-12130 is the official reference to ZombieLoad and CVE-2019-11135 is the official reference to Variant 2 (TAA).
With November 14th, 2019, we present a new variant of ZombieLoad that enables the attack on CPUs that include hardware mitigations against
MDS in silicon. With Variant 2 (TAA), data can still be leaked on microarchitectures like Cascade Lake where other MDS attacks like
RIDL or
Fallout are not possible. Furthermore, we show that the software-based mitigations in combinations with microcode updates presented as countermeasures against MDS attacks are not sufficient.
We disclosed Variant 2 to Intel on April 23th, 2019, and communicated that the attacks work on Cascade Lake CPUs on May 10th, 2019. On May 12th, 2019, the variant has been put under embargo and, thus, has not been published with the previous version of our ZombieLoad attack on May 14th, 2019.
https://zombieloadattack.com/zombieload.pdf
AMD ones here, see Ryzen Security Vulnerabilities.
https://www.cvedetails.com/vulnerability-list/vendor_id-7043/AMD.html
https://community.amd.com/community...amd-technical-assessment-of-cts-labs-research
https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/
