RAMBleed Attack – Reading Bits in Memory Without Accessing Them • Hacker News Board

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

#131

Post by mrmondo » Wed, Jun 12, 2019, 7:18 AM UTC

Dylan16807 wrote: post #120

jiveturkey wrote: post #73

Earlier quoted context omitted.

> This is a kind of obvious variant of Rowhammer, which hasn't generally been fixed AFAIK. https://en.wikipedia.org/wiki/Row_hammer#Mitigation

"optional hardware support" "some manufacturers" I think "hasn't generally been fixed" is a fair assessment. TRR is so cheap to implement and should have been made mandatory, with generous safety margins.

“RAMBleed has been demonstrated on devices with DDR3 memory chips, and Rowhammer's bit flipping on DDR4 components. DDR4 supports a defensive technique called Targeted Row Refresh, but its efficacy is uncertain. "Given the closed-source nature by which TRR is implemented, it is difficult for the security community to evaluate its effectiveness," said Kwong. "While bit flips have been demonstrated on TRR before, the extent to which TRR mitigates RAMBleed remains an open question."

https://www.theregister.co.uk/2019/06/11/rambleed_rowhammer_...

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

#132

Post by pantalaimon » Wed, Jun 12, 2019, 8:24 AM UTC

viraptor wrote: post #66

arpa wrote: post #58

Earlier quoted context omitted.

Sounds like you'd enjoy https://en.m.wikipedia.org/wiki/BLIT_(short_story)

Also Snowcrash https://en.wikipedia.org/wiki/Snow_Crash

Also this

https://youtu.be/Wm8ZoVQ_OJo

https://en.wikipedia.org/wiki/McCollough_effect

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

#133

Post by dredmorbius » Wed, Jun 12, 2019, 8:55 AM UTC

For those who find that sort of thing interesting, the domain was registered 109 days ago, February 23, 2019.

https://whois.domaintools.com/rambleed.com

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

#134

Post by thr0w__4w4y » Wed, Jun 12, 2019, 12:20 PM UTC

vardump wrote: post #94

dmitrygr wrote: post #84

Very cool and scary, but in reality actually exploiting this without a cooperative target, and a relatively quiet machine is quite unlikely. Does not mean it shouldn't be looked at, but do not lose sleep over it.

> actually exploiting this without a cooperative target, and a relatively quiet machine is quite unlikely. ... until someone does it somewhat reliably. I always assume my knowledge and imagination does not come close the collective creativity of exploiters.

Yes, this. Also, there is a saying in the security world, "Attacks only get better over time."

I consult on embedded systems, and at least one medical device I work on is directly concerned with this issue. Embedded systems (cars, elevators, medical devices) consider a different threat model than, say, a server sitting in a data center. These poor devices often sit vulnerable, physically unprotected, and often they can be acquired on Ebay, etc. and "tortured in a garage" for months on end.

Scary stuff. Good for me and my business, bad for all of us though.

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

#135

Post by mrmuagi » Wed, Jun 12, 2019, 4:37 PM UTC

nyolfen wrote: post #98

colechristensen wrote: post #88

Earlier quoted context omitted.

There have been many demos at security conferences of doing these kinds of things, "simple" things like key logging from a laptop with only a nearby radio.

how about extracting pgp keys with a smart phone microphone from 6 feet away? https://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf

> Figure 4. A mobile phone (Samsung Note II) is placed 30 cm from a target laptop.

Less impressive than 6 feet, but still impressive.

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

#136

Post by Dylan16807 » Wed, Jun 12, 2019, 5:26 PM UTC

mrmondo wrote: post #131

Dylan16807 wrote: post #120

Earlier quoted context omitted.

"optional hardware support" "some manufacturers" I think "hasn't generally been fixed" is a fair assessment. TRR is so cheap to implement and should have been made mandatory, with generous safety margins.

“RAMBleed has been demonstrated on devices with DDR3 memory chips, and Rowhammer's bit flipping on DDR4 components. DDR4 supports a defensive technique called Targeted Row Refresh, but its efficacy is uncertain. "Given the closed-source nature by which TRR is implemented, it is difficult for the security community to evaluate its effectiveness," said Kwong. "While bit flips have been demonstrated on TRR before, the e…

> While bit flips have been demonstrated on TRR before

Yeah but when I chase down references all I can find is one saying that rowhammer was possible on a Pixel phone, in turn referencing a paper that doesn't have the word 'pixel' in it. No study about how TRR effects the difficulty, or whether TRR was set up correctly. I want a chart showing bit flip difficulty vs. TRR aggressiveness. Because you can set TRR to be very aggressive with almost no performance impact on non-malicious workloads.

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

#137

Post by lyxsus1 » Wed, Jun 12, 2019, 10:44 PM UTC

taneq wrote: post #105

lyxsus1 wrote: post #104

Earlier quoted context omitted.

Is it a known phrase or your good sense of humour?

https://en.m.wikipedia.org/wiki/Turtles_all_the_way_down

Ah, thank you. William James keeps chasing me.

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

#138

Post by mayankkaizen » Thu, Jun 13, 2019, 10:21 AM UTC

taneq wrote: post #107

nine_k wrote: post #97

From the speed figures (many hours of setup and runtime, very low read rate) I can suggest that restarting your important service often, and moving it between VMs, would prevent an attack like that. In many deployments, automatic scaling and failover already provide the necessary mechanics. Then the Chaos Monkey suddenly becomes a security enforcement tool :)

> From the speed figures ... You know what software's like, though. What today takes the blood of a virgin and a dozen dribbly candles will be doable next week with a toothpick and three cc's of mouse blood.

That was ..... interesting quote.

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

#139

Post by smolder » Thu, Jun 13, 2019, 10:06 PM UTC

mycall wrote: post #102

TylerE wrote: post #99

Earlier quoted context omitted.

It can't just be turtles all the way down.

Can you make an FPGA out of an FPGA?

I'm already done making an fpga out of my fpga, and I never had one!

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

#140

Post by 2bitencryption » Fri, Jun 14, 2019, 6:57 PM UTC

joshdance wrote: post #12

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…

Relevant @patio11 article https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea... I think the marketing campaigns are awesome. Makes it much easier to get resources to fix.

Wow, that's a really excellent read. Thanks.