The SPOILER vulnerability


You recall the Meltdown and Spectre vulnerabilities, I’m sure.

There is a new potential attack vector which works in conjunction with the RowHammer class of DRAM attacks. It is intended to augment the mapping of virtual memory to physical memory. The purpose is to improve the efficiency of such attacks. Although like Meltdown and Spectre, speculative execution is still the primary mechanism leveraged by the attack. This one goes back further in history and is potentially deploy-able as far back as the Intel Core series of processors.

Like Meltdown,  it appears to be Intel-specific.  Meltdown is by far the most serious of these vulnerabilities and was reasonably easy to patch. Additionally, Meltdown was only applicable to Intel processors so AMD servers were intrinsically immune to this attack. While theoretically Spectre-class attacks can be launched against AMD processors as well as Intel (and ARM among other architectures), it’s also apparent that weaponizing these attacks is quite challenging, and particularly so for non-Intel platforms.

The new SPOILER vulnerability exploits the speculative reordering of load/store instructions to avoid pipeline stalls.

Reading the paper, it appears to be a realistically weaponizable attack at the Javascript level.  The initial phase of an attack could take as little as 30-40 seconds from the browser. The authors do state that removing high-resolution times from Javascript makes attacks more difficult. It is confirmed that they were unable to compromise the Intel SGX Secure Enclave as a result of TLB cache flushes that are performed during context switches.

However note that the vulnerability is not, per se, an attack vector itself. Instead, it only expedites the effectiveness of a subsequent RowHammer attack. Such an attack can be very time-consuming.  Single bit flips are no match for ECC memory.

A double bit flip causes an application failure at the hardware level so ECC memory is only vulnerable to RowHammer if a triple bit flip can be achieved. This requires potentially from 30 minutes up to a week to achieve, making the attack difficult on server-class hardware.

On endpoints with no error detection, such as normal PCs, of course, the attack is more effective.

However, here the attacker still has to be able to exploit the result of corrupting memory and so, to the best of my knowledge, no weaponizable RowHammer attacks have been seen in the wild.

It’s not clear if, or when, there will be any mitigations available for this attack. A Meltdown-style patch is not feasible.

The main RowHammer attack is even more difficult to mitigate. It exploits the fundamental design of DRAM and its need for a periodic refresh.

Given the huge discrepancy in price between DRAM and SRAM, therefore, it’s highly unlikely that any practical mitigation will emerge.

PS: today’s interesting security question. Why has the apparently strong password ji32k7au4a83 appeared in over 140 data breaches to date?. There’s a reason, and it shows you the complexity of producing truly secure systems.

Share this post

Share this post on your favorite social media platform.

Find this article useful?

If so please click here