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

41–50 of 141 posts

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

#41

Post by x0ner »

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…

P1) I don't see the current naming model as any worse than the disjointed CVEs of today.

P2) What if all wide-impacting vulnerabilities were treated like this, regardless of theory or not; the vulnerability still exists.

P3) Names are fairly easy to come up with.

Some of my views on why this approach is beneficial, https://medium.com/@9bplus/why-i-love-marketing-vulnerabilit...

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

#42

Post by mfatica »

cbg0 wrote: post #38
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.

Do AMD processors support it?

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

#43

Post by viraptor »

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…

> we "have to" patch because otherwise we're "not secure against this scary sounding thing."

Either you have people with security experience who can tell you if it matters in your situation, or... Well, you won't know what the right answer is and may as well default to patching since your os distribution will do it.

But I don't think it's that different for named and not named vulnerabilities. The response to management can be either "we dealt / are dealing with it according to our vulnerability management policies", or whatever you'd answer when asked about any other issue. The only difference is you may be asked in the first place.

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

#44

Post by manifestsilence »

anon_cow1111 wrote: post #24

Well, this sounds really bad. Though on a positive note, I guess we could try a similar exploit in meatspace to figure out if we're living in a simulation or something. /sarc but also maybe not

That's actually a pretty cool thought. I've always scoffed at philosophies along the lines of, "what if it's all a dream/simulation" because if it's perfect, and you only escape it through death, what's the point of holding that view? But if there's a chink in the armor, it becomes suddenly very interesting. Not that I think that's likely to pan out since it so badly violates Occam's Razor, but it's an interesting possibility.

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

#45

Post by xamuel »

tptacek wrote: post #11
horyzen wrote: post #10

I find it very amusing that they use the name "Feng Shui" for placing the victim page. For those who don't understand: https://en.wikipedia.org/wiki/Feng_shui

It's also an idiom Alex Sotirov coined 10 years ago: https://en.wikipedia.org/wiki/Heap_feng_shui

Imagine if human beings could be vulnerable to such attacks. Someone sends you a video link, you watch it, you see weird shapes appearing and disappearing for a few minutes, then the next thing you know, you wake up in a bathtub full of ice-cubes with one of your kidneys stolen.

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

#46

Post by msbarnett »

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?

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

The paper describes strategies for manipulating a target box into doing just this.

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

#47

Post by [deleted] »

2bitencryption wrote: post #35
tareqak wrote: post #7

Earlier quoted context omitted.

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.

[deleted]

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

#48

Post by [deleted] »

heybrendan wrote: post #4

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…

[deleted]

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

#49

Post by cr0sh »

heybrendan wrote: post #4

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…

This really sux - that the fix is "Move to DDR with TRR enabled - which means for many people: Buy a new computer. Or new RAM. Or new RAM, motherboard, CPU, etc - ie - a new computer; ie - spend a lot of money".

But there really isn't any other good options.

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

#50

Post by syn0byte »

expliced wrote: post #31
the8472 wrote: post #21

Earlier quoted context omitted.

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.

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.

Post reply on HN