4 ms·

Does this affect public cloud providers? Can it be used to obtain data from other VMs running on the same host?

snazz 7y ago
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....
- xoa 7y ago
  >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?).
the8472 7y ago
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.
- expliced 7y ago
  >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.
  - opencl 7y ago
    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.
  - syn0byte 7y ago
    ECC isn't effective mitigation against Rowhammer either. https://www.vusec.net/projects/eccploit/ https://www.vusec.net/projects/eccploit/ tl;dr ECC logic can't cope with 'single' errors involving > 2 bits.
    - deleted 7y ago
      [deleted]
    - Dylan16807 7y ago
      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".
rasz 7y ago
Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) should be a good counter measure.
jontro 7y ago
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

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....

xoa 7y ago
>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?).

the8472 7y ago

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.

expliced 7y ago
>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.
- opencl 7y ago
  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.
- syn0byte 7y ago
  ECC isn't effective mitigation against Rowhammer either. https://www.vusec.net/projects/eccploit/ https://www.vusec.net/projects/eccploit/ tl;dr ECC logic can't cope with 'single' errors involving > 2 bits.
  - deleted 7y ago
    [deleted]
  - Dylan16807 7y ago
    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".

rasz 7y ago

Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) should be a good counter measure.

jontro 7y ago

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