Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RAMBleed Attack – Reading Bits in Memory Without Accessing Them

rambleed.com

Post reply on HN
Print view View original

31–40 of 141 posts

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#31

Post by expliced »

the8472 wrote: post #21
polskibus wrote: post #9

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

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.

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

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#32

Post by segfaultbuserr »

akersten wrote: post #30

I am so torn about the whole vulnerability branding thing. On the one hand, it gives a great amount of visibility and motivation for brass to actually provide for getting prod patched when IT might not have had the political capital to do so otherwise. But on the other hand, I think about things like: -- What happens when the cure is worse than the disease (some variants of Spectre), and we "have to" patch because ot…

> -- What do you call it when we find another way to read RAM next year - RAMBleed2? I guess.

or RAMBleed-NG, probably.

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#34

Post by dumbfounder »

CodeMage wrote: post #27
deckar01 wrote: post #18

Earlier quoted context omitted.

> a bit is more likely to flip when the bits above and below it have the opposite charge. ... To exploit this effect, we developed novel memory massaging techniques to carefully place the victim's secret data in the rows above and below the attacker's memory row. The secret data has to be duplicated, column aligned, and have a single unallocated row between it. Controlling the alignment of the secret data seems like…

> Edit: The strategy in the paper requires allocating a bunch of physical memory from all the small blocks so that memory allocation requests from a new process are allocated deterministically to a desired physical row. Honest question, because I'm not a security expert: can you do this without having already pwned your target to such a degree that this would be unnecessary?

I am also not a security expert, but it seems like VM's that are shared in the cloud are the targets for a lot of these types of attacks. You don't need to pwn the other VM, but you don't exactly get to choose which VM's you cohabitate with to target your attacks.

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#35

Post by 2bitencryption »

tareqak wrote: post #7
tathougies wrote: post #2

Why does every new attack have a homepage these days?

I forget if heartbleed was the first one to a have a homepage or the first one to have a catchy name, but it was to help with the public relations angle of convincing CIOs or their equivalents in an organization to take the problem seriously AFAIK. Someone else here can probably answer it better.

On this subject, I'd love to see a full history of the "branded vulnerability" thing.

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#36

Post by jerf »

CodeMage wrote: post #27
deckar01 wrote: post #18

Earlier quoted context omitted.

> a bit is more likely to flip when the bits above and below it have the opposite charge. ... To exploit this effect, we developed novel memory massaging techniques to carefully place the victim's secret data in the rows above and below the attacker's memory row. The secret data has to be duplicated, column aligned, and have a single unallocated row between it. Controlling the alignment of the secret data seems like…

> Edit: The strategy in the paper requires allocating a bunch of physical memory from all the small blocks so that memory allocation requests from a new process are allocated deterministically to a desired physical row. Honest question, because I'm not a security expert: can you do this without having already pwned your target to such a degree that this would be unnecessary?

Probably not.

However, historically, these sorts of attacks always get better, not worse.

And while even that can sometimes be empty rhetoric, I will say in the last 5 years I'm seeing a lot of security attacks that are already well beyond what even my moderately-trained intuition would suggest are possible, so I have to admit I've sort of given up on trying to guess on whether or not an attack can be made practical. I've seen too many mind-blowing presentations from security researchers to think I can bound their abilities safely. I wouldn't care to bet that they won't move the attacks I already am flabbergasted can exist to some other even-more practical attack that I am flabbergasted can exist.

This is unrelated to the current matter, but let me give you an example: https://www.youtube.com/watch?v=_eSAF_qT_FY If you think that's trivially obvious, and you're confident you can predict how these sorts of things will play out in the future, more power to you, but I'm certainly not justified in that belief at my skill level. I'm just happy I can follow that presentation!

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#37

Post by xoa »

snazz wrote: post #13
polskibus wrote: post #9

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

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

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

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#38

Post by cbg0 »

pkaye wrote: post #33

> Users can mitigate their risk by upgrading their memory to DDR4 with targeted row refresh (TRR) enabled. How does one enable this feature? Is it in the BIOS?

I'm not sure if it is an option you can enable/disable in BIOS, but if your CPU and memory have support for pTRR/TRR it should be enabled.

Ivy Bridge and newer processors should support pTRR and possibly even TRR.

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#39

Post by wbl »

CodeMage wrote: post #27
deckar01 wrote: post #18

Earlier quoted context omitted.

> a bit is more likely to flip when the bits above and below it have the opposite charge. ... To exploit this effect, we developed novel memory massaging techniques to carefully place the victim's secret data in the rows above and below the attacker's memory row. The secret data has to be duplicated, column aligned, and have a single unallocated row between it. Controlling the alignment of the secret data seems like…

> Edit: The strategy in the paper requires allocating a bunch of physical memory from all the small blocks so that memory allocation requests from a new process are allocated deterministically to a desired physical row. Honest question, because I'm not a security expert: can you do this without having already pwned your target to such a degree that this would be unnecessary?

Yes. Multi-user unix systems. Potentially even from inside a browser depending on GC details.

Re: RAMBleed Attack – Reading Bits in Memory Without Accessing Them

#40

Post by mfatica »

segfaultbuserr wrote: post #32
akersten wrote: post #30

I am so torn about the whole vulnerability branding thing. On the one hand, it gives a great amount of visibility and motivation for brass to actually provide for getting prod patched when IT might not have had the political capital to do so otherwise. But on the other hand, I think about things like: -- What happens when the cure is worse than the disease (some variants of Spectre), and we "have to" patch because ot…

> -- What do you call it when we find another way to read RAM next year - RAMBleed2? I guess. or RAMBleed-NG, probably.

RAMBleed++
Post reply on HN