Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Son of Rowhammer: None of us are safe from RAMBleed

public://webform/writeforus/profile-pictures/richi-2016-480.jpg
Richi Jennings Your humble blogwatcher, dba RJA
 

Researchers have been experimenting with Rowhammer. And what they’ve found will shock you.

RAMBleed is their catchy name for an arsenal of ways to read any physical memory on a machine. Yes, any memory: It works across processes, containers, and even VMs. You don’t need any runtime privilege. Neither DDR4, ECC, nor TRR can save us.

We’re doomed. Multi-tenant public cloud is suddenly looking less attractive. In this week’s Security Blogwatch, we go live in a yurt.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: $999???

Sky falling (again)

What’s the craic? Thomas Claburn explains it smashes DRAM until it leaks apps' crypto-keys, passwords, other secrets:

Boffins from Australia, Austria, and the US have expanded upon the Rowhammer memory attack technique to create more dangerous variation. … In a paper released online … with the now obligatory vulnerability illustration and dedicated domain … Andrew Kwong … Daniel Genkin … Daniel Gruss … and Yuval Yarom … describe a way to use the Rowhammer technique as a side channel to read data that should be off limits.

This is not particularly brilliant for multi-tenant boxes in public clouds. … Rowhammer has been assumed to be relatively benign because there aren't really any security implications to flipping bits within one's own private memory. [And] one of the mitigations proposed for Rowhammer – using error-correcting code (ECC) memory as a means of ensuring memory integrity – fails to block RAMBleed.

[They] express skepticism about existing software mitigations, noting that RAMBleed can bypass software-based integrity checks and memory partitioning schemes. Hardware-based mitigations may help, though one proposed measure, PARA (probabilistic adjacent row activation) has not been widely adopted and only offers a probabilistic (rather than consistent) security guarantee. [Also] DDR4 supports a defensive technique called Targeted Row Refresh, but its efficacy is uncertain.

And Dan Goodin jumps in—RAMBleed side-channel attack works even when DRAM is protected by error-correcting code:

The new data-pilfering RAMBleed technique exploits the ever-shrinking dimensions of DRAM chips that store data a computer needs to carry out various tasks. … The attacks work because as capacitors become closer together, they more quickly leak the electrical charges that store the bits.

By combining the memory massaging techniques with [a] new side-channel attack, the researchers … were able to extract an RSA 2048-bit signing key from an OpenSSH server using only user-level permissions. … RAMBleed and the previous attacks it builds on poses a longer-term threat, especially for users of low-cost commodity hardware.

RAMBleed is able to bypass ECC. … When corrections occur, they happen in a predictable way that first corrects the error and then passes the corrected value to the software. This opens a timing side channel. … RAMBleed was able to successfully read bits stored in ECC memory with a 73% accuracy at a rate of 0.64 bit per second.

[Intel] advises using DRAM that's resistant to Rowhammer attacks. That generally includes using DDR4 [with] ECC [and] a feature known as targeted row refresh. [But] RAMBleed can bypass ECC protections [and] targeted row refresh isn't an automatic defense against Rowhammer.

Why “RAMBleed”? Kwong et al. describe Reading Bits in Memory Without Accessing Them:

Due to deficiencies in the memory modules, the RAM bleeds its contents, which we then recover through a side-channel. … The implications of violating arbitrary privilege boundaries are numerous, and vary in severity.

As an example, in our paper we demonstrate an attack against OpenSSH in which we use RAMBleed to leak a 2048 bit RSA key. However, RAMBleed can be used for reading other data as well.

We show in our paper that an attacker, by observing Rowhammer-induced bit flips in her own memory, can deduce the values in nearby DRAM rows. Thus, RAMBleed shifts Rowhammer from being a threat not only to integrity, but confidentiality as well. Furthermore, unlike Rowhammer, RAMBleed does not require persistent bit flips, and is thus effective against ECC memory.

One defense that does … protect against RAMBleed is memory encryption. This is because RAMBleed reads bits directly from memory, which are ciphertext bits in the case that memory is encrypted. Trusted execution environments, such as Intel’s Software Guard Extensions … ARM’s Trust Zone, and AMD’s Secure Encrypted Virtualization (SEV), in fact fully encrypt the enclave’s memory, thereby protecting them from RAMBleed.

We will present our paper … at the 41st IEEE Symposium on Security and Privacy in May, 2020. … This research was partially supported by a gift from Intel.

What’s the impact? DaemonProcess tries to process it:

Sounds to me like a logged in user can read memory in a completely different partition without requiring any privileged context, you are just reading raw bits from the chips and trying to figure out what they are. Once you have the hacked login details you gain entry through the front door.

Could you be a little more shouty? This Anonymous Coward swearily summarizes the threat model:

They're able USING JAVASCRIPT IN A USERLAND BROWSER to get the PRIVATE KEYS and ESCAPE THE VIRTUAL SANDBOX! That's why this is a big ****ing deal. The entire cloud, boom.

You've got a hardware flaw that even 7 rings of abstraction aren't blocking off. … Using nothing more than ****ing javascript.

Javascript is enabled by default everywhere. Virtual machines are used everywhere. This is a ****show of a problem.

Yikes. GeneralFailureDriveA is fascinated:

This is a fascinating and novel application of rowhammer principles. [But] yet again, a depressing reminder that we cannot trust modern hardware to do the most basic functions we rely on for security.

On top of all this, we have … written software that we cannot [trust]. At what point does the modern computer complexity come crashing down around our feet? We cannot simply continue adding more complexity.

And adespoton is frustrated:

What frustrates me about this is that the original Rowhammer attack was applied against smart card memory back in 1998. [So] smart card chip manufacturers introduced random timing fluctuations to protect against it.

The problem and the solution … have been known to chip developers and manufacturers for 21 years. And yet performance was continually selected over security.

So why is it that smart card chips … could be armored against these attacks, but we've still got the same dumb systems managing memory in general purpose computers?

Why indeed? iggymanz agrees:

Its our hardware design that's ridiculous. Memory should be able to have any values written with any frequency, without disrupting adjacent cells. Plenty of memory does NOT have this problem, but somehow we think it's fine for PC and server memory to have this problem because we need high density, speed and low power consumption at all costs.

How about we line up the so-called "engineers" of this garbage against the wall and shoot them as a warning to others?

Meanwhile, Carsten—@CarstenBKK—sounds utterly depressed:

Another hardware attack. The security assumptions all modern multi-user operating systems rely upon are fundamentally broken.

The moral of the story?

If it’s in RAM, it’s vulnerable—virtualization won’t save you. Got enclave?

And finally

$999 monitor stand explained

 Hat tip: Rob Beschizza


You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Jannis Andrija Schnitzer (cc:by-sa)

Keep learning

Read more articles about: SecurityInformation Security