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

121–130 of 141 posts

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

#121

Post by Dylan16807 »

syn0byte wrote: post #50
expliced wrote: post #31

Earlier quoted context omitted.

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

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

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

#122

Post by mehrdadn »

tru3_power wrote: post #118
mehrdadn wrote: post #108

Earlier quoted context omitted.

> SAL annotations Are there tools for developers to use these (e.g. with VC++), or are they all Microsoft internal?

Yup there are a few static code analysis tools that support using annotations afaik

SAL specifically, or other kinds?

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

#123

Post by colechristensen »

msds wrote: post #110
colechristensen wrote: post #57

Earlier quoted context omitted.

Real-world side channels are going to start getting more attention as the technology and techniques for extracting information from EM radiation from circuits (not radios) leaking state improve.

I was unaware that there were high-speed digital circuits that weren't also radios.

Just ones that people have particularly strong feelings about being radios

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

#124

Post by colechristensen »

mycall wrote: post #103
colechristensen wrote: post #89

Earlier quoted context omitted.

Well "special hardware to detect EM radiation" is most often software-defined radios like HackRF or BladeRF among others down to TV reception dongles you can get for a few dollars (search for RTL-SDR)

I look forward to the day when SDRs are inside smartphones.

They probably already are just hidden behind closed source firmware

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

#126

Post by hoseja »

mehrdadn wrote: post #114
ryacko wrote: post #113

Earlier quoted context omitted.

There is also this: https://docs.microsoft.com/en-us/visualstudio/code-quality/u...

I think they talk about the annotation but not the analysis tools?

https://docs.microsoft.com/en-us/visualstudio/code-quality/c...

It's part of VC++.

But I do not recommend using SAL for modern code.

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

#127

Post by scandinavian »

orhmeh09 wrote: post #119
Rapzid wrote: post #116

Can we talk about these attack names? Everything bleeds these days. "RAMSack" is a legit missed opportunity.

“Bleed” has a functional purpose; it communicates that it is a side-channel leaking information.

"Bleed" is normally just used for communicating that the exploit leaks data. See Optionsbleed, Heartbleed and Ticketbleed which are not side-channel attacks afaik.

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

#128

Post by mehrdadn »

hoseja wrote: post #126
mehrdadn wrote: post #114

Earlier quoted context omitted.

I think they talk about the annotation but not the analysis tools?

https://docs.microsoft.com/en-us/visualstudio/code-quality/c... It's part of VC++. But I do not recommend using SAL for modern code.

Oh wow. I'd used /analyze before but I hadn't realized it takes SAL into account. I thought it just does limited extra analysis without SAL. Thank you!

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

#129

Post by 29athrowaway »

rsweeney21 wrote: post #80

Shortly after I joined Microsoft in 2004, all new feature work on Windows Longhorn (Vista) was halted. There had been yet another high profile computer virus on Windows XP caused by a buffer overflow. It was an all-hands-on-deck type moment. Everyone spent weeks adding SAL (source-code annotation language) annotations to the entire Windows code base. SAL annotations enabled automated source code analysis to identify…

Firmware and microcode updates.

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

#130

Post by AnaniasAnanas »

rsweeney21 wrote: post #80

Shortly after I joined Microsoft in 2004, all new feature work on Windows Longhorn (Vista) was halted. There had been yet another high profile computer virus on Windows XP caused by a buffer overflow. It was an all-hands-on-deck type moment. Everyone spent weeks adding SAL (source-code annotation language) annotations to the entire Windows code base. SAL annotations enabled automated source code analysis to identify…

Dependent types can prevent buffer overflow attacks without any additional runtime overhead.
Post reply on HN