Live data from Hacker News

RAMBleed Attack – Reading Bits in Memory Without Accessing Them

rambleed.com

21–30 of 141 posts

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

#21

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.

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

#22

Why does every new attack have a homepage these days?

I personally find much easier to fully understand the implications of a security vulnerability that can affect me and my side projects. I'm a full time front-end dev and I do not follow security news explicitly. If severe vulnerabilities have dedicated home pages then it's easier to spread awareness and more people end up sharing the same resource thus keeping people updated easily

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

#23

Perhaps I'm missing something really obvious, but doesn't hardware-provided memory encryption solve this quite handily? You might be able to read single bits of raw physical memory from another process, but this won't tell you anything substantial about what that process is up to.

The mitigations section of the paper discusses memory encryption

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

#26

Why does every new attack have a homepage these days?

I imagine these researchers are proud of their findings and want to promote their work and their own personal brands. Name recognition is a big part of academia. You'll notice a "People" section immediately following the description of the vulnerability.

This paper was accepted at IEEE S&P, which is arguably the best security conference in the world, so I don't think these guys will be lacking when it comes to recognition!

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

#27

If I understood correctly, this is orders of magnitude worst that RowHammer, as it is kind of passive: you set some program to do the RowHammer side, within its own memory space, and then use RAMBleed to see changes from memory cells, not exactly the ones that were RowHammered. Is that it ?

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

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

#28
post #16

Anyone else love how vulnerabilities these days have full on marketing-esque campaigns backing them? In any case, if it increases awareness, I'm mostly supportive. Allow me to save some time, from TFA: > Is there a CVE number? > Yes, see CVE-2019-0174 [1]. [1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174 --- > What is RAMBleed? > Previous attacks exploited the Rowhammer effect to write (or flip) bits…

Unless your CEO loves talking about CVEs all day long, I think we should all be grateful for these good-looking marketing campaigns for serious security issues .

I whole-heartedly agree with your broader point about having sensible names and descriptions that draw necessary attention to critical flaws. (And "+1" to the excellent related article from patio11.)

But sometimes it seems to be stretched to the point of making you feel nauseated and cause extreme distraction (which can be the point in some cases, though). Still, I wish some of the less egregious issues were described with a little less hysteria, while still conveying their seriousness. (Maybe it's my weariness of dealing with them is speaking here.)

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

#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 otherwise we're "not secure against this scary sounding thing." It takes a lot of agency away from the IT department to make an informed decision about the appropriate mitigation and threat model, and turns it into a business requirement regardless of the trade-off - because brass "understands" Spectre, they don't understand CVE-1234

-- Or, theoretical exploits that aren't practical in the real world, but we spend a lot of effort or make tradeoffs to fix just because someone needs some material for their PhD.

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

Post reply on HN