RAM-ramming Rowhammer is back – to uniquely fingerprint devices Boffins at the University of California, Davis have devised a purportedly practical way to apply a memory abuse technique called Rowhammer to build unique, stable device fingerprints. UC Davis researchers Hari Venugopalan, Kaustav Goswami, Zainul Abi Din, Jason Lowe-Power, Samuel King, and Zubair Shafiq have found they can use …
Back in the old days, the memory bits were represented by single magnetic donuts - my recollection is about 3mm. These lil bits were weaved into a large plane with cross-wires. Apparently, flipping a single bit on and off fast enough (milliseconds?) would heat the poor thing up until it expired.
In the only slightly less old days, we were able to achieve the same thing (destruction of memory) by flipping a unit of memory (then called a "word") - probably using the wonderful XOR operation.
I guess there wasn't much use for something like Rowhammer back then.
> turn a core bright red
I think you have been cooking-up black holes and standing too close to the pot.
Cores got smaller than 3mm. Hell, _I_ had a plane of 2mm doughnuts, and they never let me scavenge the good stuff.
"...a Burroughs module from the late 1970s has cores of approximately 0.015 or 1/64 inches outside diameter." 0.4mm http://madrona.ca/e/coremem/index.html
While I am aware of heating via magnetic hysteresis (it is one of the generally minor losses in power iron cores), I never heard of it getting what we would call "HOT".
What would normally be hot is the high-speed transistors used to drive core in the last hi-speed earth-bound core machines. (Core survived the Apollo and even Space Shuttle flights but not as a super-computer.) The TO5 transistor cases would put a blister on your finger.
Added to that, temperature sensitivity on core threshold meant core units were on a thermostat, and heating is cheaper than cooling.
I had a couple walking-ones test programs that could be run at full speed indefinitely on PDP10 or PDP11. Never managed to heat up the core much past its standard operating temperature ... which is rather warm. It's a little known fact that most of the power consumed by Core Memory is used to heat it up, in order to keep it within the optimal working temperature. It's far easier to keep something warmer than room temperature than at or below room temperature.
That said, I remember a sales-droid trying to sell us on a similar story, explaining why the Intel 1103 was better than a 1K core module "because it would never fail due to heat". The Boss and I looked at each other and busted a gut laughing. We didn't bother telling him we were working with Intel and in fact the PDP-11 on the back wall had a prototype RAM cage in place of Core (late 1970ish).
However, I'm always willing to learn something new. Got a site where I can catch sight of a cite for this red-hot ferrite?
I've heard that some of the PDP-10 cabs could get rather warm; supposedly warm enough to cause quite serious discomfort, according to the possibly apocryphal story of an idiot boss who was told to not lean on them and did so anyway, as was his habit. I have no experience of them in person other than as a user, my college still running a pair of 10s during my time there in the late '80s, but I only saw the actual beasties themselves in photos (which also revealed the 109x to live in a curious arrangement of DECSYSTEM-20-style cabinets, albeit a fairly long row of them).
Their approach, they say, is potentially useful for fraud detection. However, they acknowledge the system does have some flaws – it could crash fingerprinted devices or wear out their memory modules for example.
No white hat good guys would ever do that, then. However, the black hat bad guys might use the fingerprinting info as a clue to what further setup-specific hacks might yield results.
Per the article - stopping bots. I can see the use for this in a DDOS or even a queue-for-service scenario, if there were such a thing as a reputable global register of devices with compromised/uncompromised flags. Not that I'd line up in any particular hurry to let them rowhammer my device and add me to the registry as "ok".
> stopping bots
That's just an excuse, and an extremely fallacious one too: According to their own claims, all it can do is catch "a computer that attempts to pretend to be multiple machines", and how often is that a problem? If you want to catch a computer pretending to be multiple different users the IP address might be enough. Not to mention way faster and cheaper.
Mostly it will be used to fingerprint computers for marketing purposes (that's where the money is), and also to try to destroy them remotely for lolz and petty online vengeance...
"Fight fraud with Rowhammer", sure, pull the other one.
Plus: you'd have to allow the fingerprinting software to be installed on the computer you're probing (e.g. the thing which you suspect of being a bot). But if it's a malicious actor, it will fake its own fingerprint results.
I can only see this sort of fingerprinting being used by software vendors to enforce licensing - much in the way that they used to write intentionally bad sectors to floppy disks in the 1980's.
The effect was noticed in early RAM (Intel 1103) back in the very early 1970s. Except back then, we called the effect a more logical "induced disturbance errors".
It was pretty much ignored, because you had to have access to the machine to do anything with it ... and if you had access to the machine, security was already compromised. Of course, since then networking has become nearly ubiquitous, which changes things somewhat ...
Quote: "... to uniquely fingerprint devices..."
Well.....how about:
(1) MAC Address
(2) sudo dmidecode |grep Serial
(3) sudo dmidecode |grep "Asset Tag"
Perhaps I'm paranoid.......but the suggestion in this article sounds like an invitation to crash targets, or even destroy remote hardware......
......especially when fingerprinting is MUCH easier (see above)!!!!!
Back in the late 1980s, there was a company in Taiwan which "recycled" MAC addresses on its clones of NE1000/2000 ethernet cards. When you got a new batch of cards which matched the MAC address of one or more cards on your existing LAN[0], much hilarity ensued. As a consultant, the first time was the worst ... after that, the symptoms were fairly obvious. I probably ran across the problem at a couple dozen small companies between '88 and '91ish, and then again (!!) in the mid-late '90s, when people started recycling old Netware kit for Windows networks at home.
[0] An "impossible event", at least according to Novell and IEEE.
You can change Mac addresses, in fact Android and apple devices do it by default, so if you have a device monitoring system in place (I use firewalla to better limit my kids ipad usage, and just general security), you have to explicitly turn that off for the SSID in the settings. Fortunately turning it off for a selected network leaves Mac address randomization in place when traveling.
> Centauri could accidentally crash a user’s device by flipping a sensitive bit reserved for the OS. In our experience, however, we see that such occurrences are extremely rare.
Rare, because the rest of the time it is causing all the userland programs to crash on now-bad pointer accesses or just give insane results.
Which is as bad as crashing the OS, as I don't switch the box on because I like the idea of running the OS, I do it to run the applications!
At least if the OS dies that then prevents me from using the insane results and making things worse ('"Ok, that's the wages run done, it all went very smoothly.").
Identifying bots by fingerprinting in 2MB chunks of physical RAM.
Well, that may catch all the bare metal machines that are running continuous bot attacks against the one target, because we all know that is bots work. Nobody ever runs up VMs to increase their bottage per box.
And there certainly aren't any armies of suborned PCs asking their CandC channel for their next target.
Nope, taking non-trivial time (three minutes! even 9.92 seconds of hard core memory bashing is noticeable) to identify and the block all those standalone machines will be well worth the effort.
BTW they are going to run that check how often? Every time you post there is a long pause and non-zero chance of hardware damage? That'll do wonders for social media.
For that matter, how is code with such a long run-time going to get onto and stay on the target long enough to finish? The "protected" site is going to infect your machine with malware? Or convince browser authors to include it ("Edge 4 - smoking!")? And, of course, all bots actually run from browsers, none of them use comms libraries.
And there was I thinking ECC RAM stopped Rowhammer.
I was wrong: VUSEC: ECCploit: ECC Memory Vulnerable to Rowhammer Attacks After All
Although it does slow it down somewhat. I was hoping it gave a good incentive for ECC RAM to become the default. Ah well.
(Oh, and I like the team's Q&A:
Q: You don’t have a logo, do you live under a rock?)A: No. But here’s some nice artifact [sic] that we generated based on one of the ECC implementation that we reverse engineered.
> I was hoping it gave a good incentive for ECC RAM to become the default.
Actually with DDR5 ECC became the default. IMHO simply a workaround to keep the price down and yield up since a dead bit does not cause a visible problem. But there is still a difference: DDR5 RAM which does not expose ECC to the CPU, and those which expose ECC info to the CPU and mainboard which are used in better machines. All consumer Ryzen can utilize that information, and even Windows logs such an error nicely in its eventlog.
In my case with DDR4+ECC I get an Windows "event id 47 WHEA-Logger corrected hardware error, component memory" for single-bit errors when I overdo the overclocking instead of corrupt data or a possible crash. The machine suddenly slow down a lot, but keeps going so you can do a clean exit and shutdown. Server CPUs (Epyc/Threadripper/Xeon) are better at handling that situation with less slow down, but for a consumer CPU this is fine.
As for the hamming code itself: It would be easy to extend it to make two-bit errors correctable, and three bit errors detectable. Without needing more ECC-bits. Various Server CPUs (Xeon/Epyc) use a sort-of-similar trick called "chip-kill" (or named differently on various other CPUs and vendors), where multiple ECC-RAM are interleaved in such a way that it allows a complete RAM-chip, not the whole module though, to die without crashing the machine.
Or they could implement the Music-CD error correction algorithm on RAM for consumer CPUs, giving us a whole new level of robustness.
Actually no.
The current ECC uses 72 bit width, actually a hamming 120/7 + parity over the 7 bits. Where the 120 bits part is simply cut off at 64, and everything beyond is "always zero", resulting in 64+8 bits.
But there is no real problem expanding that simple method to 247/8, 502/9 and so on, so you can have two sets of different parity bits still only needing 1/8th more RAM, or a ninth chip just for ECC. An example would be using 8191/13 + parity, still leaving 2 extra bits for more cross ECC, cutting off everything after 4096 (i.e. define always zero). Giving you 16 bits ECC per 4k page, as most current operating systems address their RAM using 4k pages. Uses 1/256th amount of bits instead of 1/8th with more error correction.
As far as "IBM Chipkill" is concerned: That is more than just two bits of error, and it works. User by Acer, Apple, Dell, Fujtisu-Siemens, Sun, Silicon Graphics, IBM etc. The AMD and Intel server CPUs can do it too of course.
I recommend watching this video, yet the best explanation how ECC works I have found. And it shows how and why it is easy to extend.
> but you can look it up
Time for you to update your skills and look it up!
Too many scientists are getting grants to produce stuff that has little benign purpose, but which can easily be exploited by dictatorships and the military to ruin lives. There should be a prize for this. The Oppenheimer award, for scientists who enabled more death and destruction than their fellows.
You might be able to dodge this by randomly virtually readdressing memory.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
