back to article RAMBleed picks up Rowhammer, smashes DRAM until it leaks apps' crypto-keys, passwords, other secrets

Bit boffins from Australia, Austria, and the US have expanded upon the Rowhammer memory attack technique to create more dangerous variation called RAMBleed that can expose confidential system memory. The memory integrity issue tied to Rowhammer was known to Intel since at least 2012 and began to be explored in academic …

  1. Steve Aubrey

    Domain squatting

    I think I'm going to try and guess the next trendy vulnerability name, then register the domain, and hold out selling it to the buyers. (anized)

    I'll be rich. Eventually. I think.

    1. Blazde

      Re: Domain squatting

      Rooting for the guy who's been squatting for the last 19 years. It can only be a matter of time before these blockbuster vulns get promoted with their own classic rock soundtrack tie-in.

      1. Steve K

        Re: Domain squatting

        Could it be Geno Washington?

    2. Ken Moorhouse Silver badge

      Re: I think I'm going to try and guess the next trendy vulnerability name...

      Bad news I'm afraid. is already taken.

  2. abhijeets

    Boffins Blast boards to boost bits! *bow*

  3. swm Silver badge

    I don't see how ECC can be bypassed unless they can reliably flip several bits in a word.

    In any case, nothing is safe any more.

    1. Flocke Kroes Silver badge

      Too defeat ECC

      When ECC detects an error it causes a delay while preparing the corrected data. The researchers detected this by timing instructions. ECC is an extra layer that slows this attack but does not prevent it completely.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too defeat ECC

        "When ECC detects an error it causes a delay while preparing the corrected data."

        That is not an inherent feature of ECC memory designs, although it may well be a common misfeature in many 'modern' system implementations.

        1. theblackhand

          Re: Too defeat ECC

          "That is not an inherent feature of ECC memory designs, although it may well be a common misfeature in many 'modern' system implementations."

          My understanding of DRAM (with or without ECC) is that write operations require one operation and read options require a read operation followed by a write operation. Note I'm making no assumptions about cycles required per operation.

          If ECC detects a correctable error, there is a small delay while the correct data/ECC information is calculated before being written back resulting in a small delay. This delay is what is being detected.

    2. Tom Paine

      They make clear on the site that ECC makes no difference, because they're reading data from adjacent memory, not writing it.

      1. Flocke Kroes Silver badge

        Now you got me confused

        They fill row X with either zeroes (or ones), then repeatedly make pairs of connections to sshd, and by magic arrange for sshd to put its decrypted key in rows (X+1) and (X-1), thus hammering row X and possibly causing a bit to flip in X. Later they read through X looking for the bit flip. ECC should detect the flipped bit and correct it so they should read zeroes (or ones) but with a tiny delay.

    3. Snake Silver badge

      Nothing is safe...?

      I'm simply left wondering if this attack is "practical" in the real world: the article, and indeed the white paper itself, makes no mention of system resources used during the attack process. Is the system load so small as to be unnoticeable, or does this attack create an overall resource load that just about any blind [user] will see performance degradation and feel 'something is wrong'? Sure, they could slow down the data acquisition process, but then will you attain data that is actually useful in real life (see below)?

      It took 4 hours to acquire enough information to reverse-engineer a piece of data (an encryption key). That assumes, therefore, that a secure session, using said key, is indeed active for the full 4 hours. Do users stay on an SSH-secured, vulnerable-data activity for that long under normal usage patterns? I don't think so.

      1. Michael Wojcik Silver badge

        Re: Nothing is safe...?

        Do users stay on an SSH-secured, vulnerable-data activity for that long under normal usage patterns? I don't think so.

        It needn't be a "vulnerable-data activity". If someone's using a conventional interactive SSH connection for 4 hours, the attack could steal their session key, then hijack the session. That alone will generally be a serious attack. Or consider, say, a CI test run against a remote slave with an open connection so it can poll the output; hijacking that might give the attacker access to modify source and the like.

        That assumes, therefore, that a secure session, using said key, is indeed active for the full 4 hours.

        It assumes the data being attacked is in memory during the attack. It doesn't assume there's an "active session". Interactive SSH sessions are not the only use of secrets in IT. A straightforward variant of their attack could be used against the private key for an HTTPS server's certificate, for example. It's trivial to keep an HTTPS server's private key(s) in more or less continual use for hours, just by making connections. Unlike a session key, the private key corresponding to a certificate is a long-lived secret.

  4. Jou (Mxyzptlk) Silver badge

    Time for SRAM and MRAM?

    Maybe we have to switch to SRAM soon. The downside is it takes more space and therefore is more expensive. For normal PCs only CPU caches are SRAM.

    Or MRAM, which manages to keep the data over decades, even when birds nested on it ;). Weren't there several MRAM methods in the pipeline to get it down to usable size instead of having literally every bit visible to the eye?

    1. Christian Berger

      We can't do that...

      ... as, thanks to overly complex browser standards, an average computer needs gigabytes of RAM. SRAM is a lot more expensive than any form of DRAM, particulary at those sizes.

      In short, unless we get out of our browser mess, we're doomed. If we get out of our browser mess, we need so little memory we can use DRAM.

      Also browsers are the main problem here. It's the only place where you have to run untrustable code from untrusted sources.

      1. Tom Paine

        Re: We can't do that...

        Apart from email clients, of course. And the Office applications, when you open an attachment or download an office file. And PDF viewers, readers likewise.And, and,...

        1. John Brown (no body) Silver badge

          Re: We can't do that...

          You forgot Flash. It's essential. Really. </sarc>

      2. JohnFen

        Re: We can't do that...

        " It's the only place where you have to run untrustable code from untrusted sources."

        But you don't have to do that, even though most people do.

      3. Michael Wojcik Silver badge

        Re: We can't do that...

        It's the only place where you have to run untrustable code from untrusted sources.

        Unless you have a computer that runs programs in different security domains, as the vast majority of general-purpose computers do.

        As a non-privileged system user, I write a Rowbleed process that runs in the background, attacking NTLM hashes. Then I use a bit of social engineering to get a domain admin to log on to my machine to investigate some mysterious "problem" I'm experiencing. I hijack the session and create a new domain admin account for myself.

        My organization has some internal HTTPS servers that host applications from different departments. I have access for a lowly HR app, but I use it to run a Rowbleed attack on the private key for the server certificate. Then I impersonate the server on another machine, and with a bit of DNS cache poisoning I MITM a finance app.

        We run a variety of applications on an in-house VM farm. My "test" program for some innocuous app is actually a Rowbleed attack against sensitive applications, hijacking ... oh, whatever. You should get the picture.

        We run sensitive applications in a public cloud. Could untrusted code possibly be running on the same hardware? Inconceivable!

        And, of course, we have the problem of untrustworthy code installed by users in vast numbers, because they have no expertise in evaluating whether they should trust it. And exploitable BOFs and other bugs in applications that process untrusted data such as image and document files. And malware injected into the software supply chain.

        In short (yes, yes, too late), the idea that browsers are the only hives of scum and villainy on the typical general-purpose computer is laughably wrong.

    2. theblackhand

      Re: Time for SRAM and MRAM?

      From an electronic perspective, SRAM requires ~6 transistors per bit to create a flip-flop switch while DRAM requires a single transistor per bit for memory functions.

      The implication is that for a given memory area, DRAM gives you 6x the capacity of SRAM, so you would likely look at improving ECC schemes to make them detect/correct more errors, as most ECC requires 36 bits per 4 bytes to operate successfully (a 12.5% overhead) for detecting 2-bit errors or dead chips.

      Based on increasing memory sizes, there is a very good argument for moving to ECC as standard anyway as the reliability benefits would outweigh the additional costs if ECC was the standard and was priced ~12.5% higher versus the current 20%+ premium.

      1. Jou (Mxyzptlk) Silver badge

        Re: Time for SRAM and MRAM?

        I already did that. Any Ryzen 2xxx supports ECC, so i did choose a mainboard which has ECC on it's feature list. The more RAM you have the more ECC makes sense.

  5. Claptrap314 Silver badge


    Anybody home? You CANNOT share systems in the cloud if sensitive data is involved.

    Just stop.

  6. don't you hate it when you lose your account

    A fish tank

    So the cpu is unsafe, now the memory. After taking all the attack vectors out of my box have to use it for something. Now just got to stop the fish using Facebook

  7. BinkyTheMagicPaperclip

    I would have thought guard pages around applications would prevent this, if it relies on adjacent allocations..

    1. cbars

      think this is a physical exploit rather than logical. So even though a guard page would be logically wrapped around the address in question, physically some blocks of memory can still be next to your page, hence read/written to. I am not an expert.

      1. BinkyTheMagicPaperclip

        Granted, but as this exploit is using the buddy allocator to find appropriate pages to look at, the host OS surely must be able to do the same thing and deny them that access.

  8. Anonymous Coward
    Anonymous Coward


    Early DDR4 DRAM did not all have Targeted Row Refresh. I wonder if the DDR4 demonstrations really did beat TRR ........

    1. Anonymous Coward
      Anonymous Coward

      Re: TRR

      DDR4 TRR is supposed to address this where implemented.

      My suspicion is that as its a "server feature" most of the servers will also have ECC so between the two, a current server is likely to be immune to rowhammer.

      Given the difficulty in changing bits in the first place in addition to these mitigations, I'm a little skeptical of the impact of Rowhammer/RAMBleed.

      1. W.S.Gosset Silver badge

        Re: TRR

        > a current server

        That's a powerpoint, isn't it? Or a generator.

        ... I'll ... icon

  9. DaemonProcess


    I am wondering if we finally have a way of completely bypassing the firmware controlled partitions on IBM mainframes - in theory, the ones that run Linux anyway.

    Any experts on here have an opinion ?

    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.

    At 4+ hours of solid CPU it would cost you a bit in MIPS charges. Also the 160% (?IIRC) spare installed ECC RAM is a mitigation.

    Having done it with Linux, they can then see if a similar attack is possible in AIX and any other o/s that temporarily stores provided credentials in memory.

    1. Anonymous Coward
      Anonymous Coward

      Re: MF?

      Its a hardware level attack, so it can be used against any container even with firmware controlled partitions as the memory protections prevent containers accessing other containers physical memory, not adjacent rows.

      The challenge is how the containers are laid out relative to the physical memory layout.

      i.e. if you have 10 x 64GB RAM modules, 64GB servers and your attacking container and intended victim container are on separate modules, no attack is possible. I'm unsure if there are any TLB protections that may assist with row hammer.

      IBM also claim hardware like RAIM is resistant to Row Hammer ( but as long as you are still able to rapidly cycle row reads across a targeted row (or rows in the case of RAIM as you would hit multiple rows at once) you still potentially trigger neighboring bit changes in row-1 and row+1.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like