Researchers use Rowhammer bit flips to steal 2048-bit crypto key | Hacker News Reader

Researchers use Rowhammer bit flips to steal 2048-bit crypto key

arstechnica.com

218 pointswalterbell29 comments

Discussed previously: https://news.ycombinator.com/item?id=20157291

> "TRR makes it more difficult to find bit flips," Kwong, the University of Michigan researcher, wrote in an email. "Not all DDR4 has TRR enabled, and implementations vary substantially by vendor, so it is difficult to pinpoint exactly how much safer TRR is against Rowhammer. TRR's susceptibility to RAMBleed is an open research question."

Samsung added TRR (Target Row Refresh) to their memory, see slide 15 of this 2014 presentation, http://aod.teletogether.com/sec/20140519/SAMSUNG_Investors_F....

From https://arstechnica.com/information-technology/2016/03/once-...

> Third I/O employees tested 12 varieties of DDR4 chips, and it didn't take long for eight of them to succumb to bitflipping. The first DIMM to fall was Crucial Ballistix Sport model manufactured by Micron. Ultimately, the researchers also carried out successful Rowhammer attacks against other Crucial- and Micron-branded DDR4 modules, as well as DIMMs from Geil. Interestingly, DIMMs from G.Skill were able to withstand the tests.

From the linked 2016 paper, http://www.thirdio.com/rowhammer.pdf

> Of the twelve memory modules we tested, eight showed bit flips during our 4-hour experiment. And of these eight failures, every memory module that failed at default settings was on DDR4 silicon manufactured by Micron. The Geil branded modules contained SK Hynix and the G.Skill modules contained Samsung silicon.

I was curious if there is any indication of vulnerability between Rowhammer attacks and running Memtest86, a procedure I've been doing on new builds for many years, and it's a program that IIRC tests for all sorts of RAM issues (usually just being plain faulty) by looking for bit flips.

Turns out they do test for Rowhammer vulnerability, though I am not expert enough to know how thorough this may be:

> Test 13 - Hammer Test:

> Starting from MemTest86 v6.2, potentially two passes of row hammer testing are performed. On the first pass, address pairs are hammered at the highest possible rate. If errors are detected on the first pass, errors are not immediately reported and a second pass is started. In this pass, address pairs are hammered at a lower rate deemed as the worst case scenario by memory vendors (200K accesses per 64ms). If errors are also detected in this pass, the errors are reported to the user as normal. However, if only the first pass produces an error, a warning message is instead displayed to the user.

https://www.memtest86.com/technical.htm

Ugh, I just realized memtest86 is now closed source proprietary software. While the old open source variant is still for download and memtest86+ exists it doesn't seem to be active anymore.

Does it need to be active? Have there been significant advancements in the realm of RAM testing?

Well, testing for rowhammer would be one thing that comes to mind ;-)

Also the change log explicitly mentioned support for individual CPU generations (and the last release was 2013) though I don't know how relevant that is or whether it's just cosmetics. Also phrases like "better timings detection" makes you wonder whether updates for newer types of memory are required.

The open memtest86+ doesn't boot from EFI, which is a significant drawback.

Right, it took me a while to figure that out half a year ago. Didn't realize bios was set to efi only and memtest wouldn't boot from USB. I wonder if that would require a major rewrite or if it's mostly just writing new bootstrap code. Since it's 32 bit code with PAE it's doing funky things like relocating itself at runtime to access more than 4 GB of ram.

The hardware vulnerabilities of recent years make me believe that we live in most cyber vulnerable era when any information that is in digital format should be considered as not secured.

Even say, a fully patched iPhone. Especially if it is stolen/seized and assuming the security can’t already be bypassed...they just wait a couple months and an exploit will emerge that will slice through that now-unpatched phone like butter.

The hardware was always pretty vulnerable (especially to rogue DMA devices). If anything the exotic nature of these attacks shows we are through the low hanging fruit.

There was never a time the hardware was secure though. That was always just wishful thinking. People were wirelessly reading data on CRTs back in the 90s. TEMPEST research is many decades ahead and the private sector is just waking up to side channel attacks.

Future AIs are going to need those for taking over the remains of our infrastructure when we have destroyed our habitat and became extinct. #cyberdarvinism

Computers are only as trust-worthy as the people using them, which is to say - not much at all.

> our techniques only require the attacker to allocate and deallocate memory and to measure instruction timings

Would a device like the XB1 or PS4 be susceptible to one of these cross channel attacks?

Most likely. The degree of the vulnerability is the question.

GDDR4 is also affected?

"GDDR4 is based on DDR3 SDRAM technology"

The only real difference, afaict, is the speed is achieved with higher bitwidths (512bit vs 64bit) than regular SDRAM, so it is very likely to suffer the same vulnerabilities.

Duplicate, but without the press hype: https://news.ycombinator.com/item?id=20157291

I'm curious if this works when the RSA key is spread across multiple DDR sticks. I have 4 sticks of 8GB each in my home desktop. Would the key be contained in just one? Spread among multiple sticks? If it is spread, would it completely foil the attack, or just make it take longer?

Actually, it might make the attack faster, especially if the spread is across multiple memory channels or controllers?

I wonder if this affects my machine (x200) since it's from 2008 and according to this site rowhammer affects DRAM modules manufactured from 2010 to preset. https://brica.de/alerts/alert/public/1238748/rowhammer-the-e...

Did you mean present?

Yes, sorry about that.

There are two kinds of people; Those who can extrapolate from incomplete data

I suspect they state 2010 since they only tested against DDR3L, there's probably nothing to stop plain DDR3 being vulnerable though.

Microsoft's Midori skunkworks OS had eschewed hardware memory controls and instead relied on bytecode verification ensure cross-process safety.

I wonder if that could fix the problem?

I'm curious if lowering memory clock speed, timings and/or raising voltage would effectively render these kinds of attack invalid.

Didn't manufacturers just throw their hands up at rowhammer?

Yeah. They punted. Put the problem in the spec and make it someone else’s problem.

Reply on news.ycombinator.com