News for hackers. Stuff that matters.

A comment on RAMBleed Attack – Reading Bits in Memory Without Accessing Them.

Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by polskibus on Tuesday June 11, 2019 @02:14PM (#20158016)
Does this affect public cloud providers? Can it be used to obtain data from other VMs running on the same host?
[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by rasz on Tuesday June 11, 2019 @02:39PM (#20158261)
Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) should be a good counter measure.
[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by the8472 on Tuesday June 11, 2019 @02:35PM (#20158221)
If this attack is a concern then so is rowhammer. So you can basically ask whether cloud providers have mitigated rowhammer.

AMD's SEV might help protecting VMs from each other.

[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by expliced on Tuesday June 11, 2019 @02:48PM (#20158339)
>unlike Rowhammer, RAMBleed does not require persistent bit flips, and is thus effective against ECC memory commonly used by server computers.

Seems like mitigations for Rowhammer is not enough for RAMBleed.

[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by opencl on Tuesday June 11, 2019 @03:56PM (#20158961)
SEV is a completely different thing than ECC. It encrypts the memory. RAMBleed reads raw physical bits which are encrypted and thus useless when SEV is enabled.

The paper even specifically says that SEV and other similar technologies protect against this.

[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by syn0byte on Tuesday June 11, 2019 @03:32PM (#20158751)
ECC isn't effective mitigation against Rowhammer either.

https://www.vusec.net/projects/eccploit/

tl;dr ECC logic can't cope with 'single' errors involving > 2 bits.

[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by Dylan16807 on Wednesday June 12, 2019 @12:46AM (#20161842)
It has to cause a huge amount of single-bit errors to find a spot suitable for a three-bit error.

If these errors are actually treated as errors, then chips will be disabled or processes will get blacklisted long before they can be used to exploit.

So this is really "ECC is often configured wrong", not "ECC isn't effective".

[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by jontro on Tuesday June 11, 2019 @05:58PM (#20159888)
Not sure if this attack is feasible cross VM as long as the memory is not deduped/over provisioned. You need to make sure the victim allocates memory between the attacker controlled memory. Edit: As long as the memory is not deduped on the VMs it should not be possible since it won't be interleaved
[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by snazz on Tuesday June 11, 2019 @02:22PM (#20158083)
It sure sounds like it—have there been any responses from the major cloud providers? This doesn’t exactly seem like something that can be patched easily....
[ Parent | on HN ]
Re:RAMBleed Attack – Reading Bits in Memory Without Accessin... by xoa on Tuesday June 11, 2019 @02:59PM (#20158426)
>have there been any responses from the major cloud providers

There does seem to recently have been an increase in having HSMs be part of cloud offerings, and while that's a good idea in general issues like this may be part of it too. One issue with this attack is that even in research conditions it seems to be pretty fundamentally slow. It took them 34 hours to do the setup phase and another 4 hours of reading, all going after a few kilobytes (.31 bits/s, accuracy rate of 82%). Which could still matter a lot when it comes to cryptographic keys since those are all small, but it's not clear is or ever could be feasible for sniffing significant amounts of confidential content data. It's more that if credentials can be harvested that'd be the steppingstone towards taking over. So if keys are just plain moved to a minimal blackbox outside the system entirely and on which no customer code of any kind runs, that seems like a real mitigation to this particular leak? I mean, even beyond any basic improvements to DRAM (or successors to DRAM, I wonder how some of the NVDRAM research like future gens of Optane handle this?).

[ Parent | on HN ]