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

Nethammer: Inducing Rowhammer Faults Through Network Requests

arxiv.org

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#11

Post by justin66 »

rasz wrote: post #7
corv wrote: post #2

It’s about time Intel offers consumers ECC RAM support.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

Do you have any links to more information on that? Googling "row access counters" leads to a lot of comments you've made on the internet, and nothing else.

I'm skeptical that "ECC won't help," that's not a commonly held opinion. It might be true but it'd be interesting to read some actual analysis as to why.

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#12

Post by Ajedi32 »

justin66 wrote: post #11
rasz wrote: post #7

Earlier quoted context omitted.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

Do you have any links to more information on that? Googling "row access counters" leads to a lot of comments you've made on the internet, and nothing else. I'm skeptical that "ECC won't help," that's not a commonly held opinion. It might be true but it'd be interesting to read some actual analysis as to why.

ECC may indeed help, but it wouldn't really fix the root of the problem: the fact that bit flips like this can happen at all.

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#13

Post by toast0 »

rasz wrote: post #7
corv wrote: post #2

It’s about time Intel offers consumers ECC RAM support.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

ECC doesn't solve rowhammer, but it raises the difficulty.

If you only get a single bit error, ECC will fix it, and increase a counter / raise a usually slow interrupt, if you get a lot of them, perf will be impacted, and the operator should notice.

If you get a double bit error, ECC will (generally) halt the os, and the operator will definitely notice. -- you won't get to try very much.

If you get a multi bit error, maybe you can do your nefarious task.

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#14

Post by jnwatson »

justin66 wrote: post #11
rasz wrote: post #7

Earlier quoted context omitted.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

Do you have any links to more information on that? Googling "row access counters" leads to a lot of comments you've made on the internet, and nothing else. I'm skeptical that "ECC won't help," that's not a commonly held opinion. It might be true but it'd be interesting to read some actual analysis as to why.

From the original paper, "For example, SECDED (single error-correction, double error detection) can correct only a single-bit error within a 64-bit word. If a word contains two victims, however, SECDED cannot correct the resulting double-bit error. And for three or more victims, SECDED cannot even detect the multi-bit error,leading to silent data corruption. Therefore, we conclude that SECDED is not failsafe against disturbance errors."

The challenge for the attacker is to produce a 3 or more bit failure before a 2-bit failure occurs, which would trigger some alarms. I haven't seen any research on the feasibility of such an attack.

Additionally, there are stronger ECC schemes than SECDED, for example the one in IBM's ChipKill. It is hard to imagine a RowHammer attack that could remain undetected with such a scheme.

It is fair to say that ECC memory raises the bar for attackers.

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#15

Post by rasz »

justin66 wrote: post #11
rasz wrote: post #7

Earlier quoted context omitted.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

Do you have any links to more information on that? Googling "row access counters" leads to a lot of comments you've made on the internet, and nothing else. I'm skeptical that "ECC won't help," that's not a commonly held opinion. It might be true but it'd be interesting to read some actual analysis as to why.

google target row refresh, TRR

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#16

Post by nyolfen »

rasz wrote: post #10
ccnafr wrote: post #3

How is this different exactly from Throwhammer?

Throwhammer: > 9.375 million packets per second Nethammer: > 1 024 000 packets per second over a 500 Mbit/s connection ......Hence, we conclude that in theory... Both currently at best lead to server crash, and are highly impractical.

it seems eminently plausible to me to carry out an attack from a device on the same network, cohosted at the same facility, etc

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#17

Post by nickpsecurity »

jnwatson wrote: post #14
justin66 wrote: post #11

Earlier quoted context omitted.

Do you have any links to more information on that? Googling "row access counters" leads to a lot of comments you've made on the internet, and nothing else. I'm skeptical that "ECC won't help," that's not a commonly held opinion. It might be true but it'd be interesting to read some actual analysis as to why.

From the original paper, "For example, SECDED (single error-correction, double error detection) can correct only a single-bit error within a 64-bit word. If a word contains two victims, however, SECDED cannot correct the resulting double-bit error. And for three or more victims, SECDED cannot even detect the multi-bit error,leading to silent data corruption. Therefore, we conclude that SECDED is not failsafe against…

Not to mention the schemes that treat RAM as untrusted with cryptographic, integrity checks. Those architectures are making more sense than ever now.

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#18

Post by als0 »

rasz wrote: post #7
corv wrote: post #2

It’s about time Intel offers consumers ECC RAM support.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

And TRR itself is not sufficient. From the paper "The idea of TRR is to refresh adjacent rows if the targeted row is accessed at a high frequency. More specifically, TRR works with a maximum number of activations allowed during one refresh cycle, the maximum active count. Thus, if a double-sided Rowhammer attack (Section 2.2) is mounted, and two hammered rows are accessed more than the defined maximum active count, the adjacent rows (in particular the victim row of the attack) will be refreshed. As the potential victim rows are refreshed, in theory, no bit flip will occur, and the attack is mitigated. However, in practice, bit flips can be further away from the hammered rows and thus TRR may be ineffective"

Re: Nethammer: Inducing Rowhammer Faults Through Network Requests

#19

Post by rasz »

als0 wrote: post #18
rasz wrote: post #7

Earlier quoted context omitted.

ECC wont help, you need row access counters(target row refresh/TRR) directly in ram chips, or in memory controller. With switch to DDR4 JEDEC had a chance of standardizing those mitigations, but that would cost additional cents per chip, cant have that!

And TRR itself is not sufficient. From the paper "The idea of TRR is to refresh adjacent rows if the targeted row is accessed at a high frequency. More specifically, TRR works with a maximum number of activations allowed during one refresh cycle, the maximum active count. Thus, if a double-sided Rowhammer attack (Section 2.2) is mounted, and two hammered rows are accessed more than the defined maximum active count, t…

I read that paper. Next iteration or TRR could have cascaded adders with dividers for X neighbor rows. But first we need JEDEC to grab current industry players by the throat and force their colluding asses to at least start doing something by adopting TRR in desktop/server products :(
Post reply on HN