My first gen Toshiba Chromebook ran the test 130 minutes without an error.
Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
81–90 of 103 posts
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#82Earlier quoted context omitted.
A few years ago I built a home PC for myself and bought an i5 sandy bridge processor with an appropriate motherboard. A few months later it was found out that a huge batch of the SATA controllers shipped on those types of motherboards were faulty[0]. Back then, Intel made a statement recalling all faulty motherboards and shipping out new ones, I just contacted my retailer where I purchased my board, sent it for RMA a…
Intel has a good history of recalls and replacements of their motherboards and processors. The Pentium FDIV bug comes to mind immediately, as does the recall of motherboards with the faulty 820-series memory translation hub.
Actually, Intels behavior with the FDIV bug was originally anything but good. They downplayed the bug and refused to recall them. Then they started offering replacements if you could prove that the bug affected you.
It wasn't until the whole thing turned into a giant PR disaster that they started a generous exchange program. That whole affair is basically the reason that Intel is much more forthcoming with errata these days.
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#83Earlier quoted context omitted.
If I understand correctly, Intel doesn't even ship a consumer CPU (i.e., a non-Xeon) that supports ECC. (Don't know about AMD.)
> Intel doesn't even ship a consumer CPU (i.e., a non-Xeon) that supports ECC. Not true - there are some Atoms that do, but they're targeted at NAS type uses. It is the case you can't get Core-series processors with ECC. AMD used to offer very broad support for ECC, but data integrity clearly didn't win market share.
data integrity clearly didn't win market share
It requires more expensive, compatible DRAM right? Knowing that, it shouldn't really be super surprising. Enabling it on die is just one piece of the equation.
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#84The starting research that enabled this security work appeared last year at ISCA, but didn't fully discuss the security implications: https://www.ece.cmu.edu/~safari/pubs/kim-isca14.pdf
I noticed the security implications of "memory that doesn't always behave like memory" when that paper came out a few months ago and was discussed briefly on HN:
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#85Earlier quoted context omitted.
I believe some pay TV smartcard hacks also made use of clock glitching, basically sending a shorter-than-usual clock pulse that means some of the internal signals don't make it to their destinations on time. The pay TV hacking industry had some pretty clever tricks a decade or two ago.
They were quite cool. From memory, I think one card had some internal startup check that checked to see if its EPROM got marked by the "Black Sunday" countermeasure and then hung itself. The hackers, having a ROM dump and having knowledge of how many clock cycles each instruction took the CPU, knew that it was at ~clock cycle 525 or so that this internal check happened. Knowing that the instruction was a "Branch if e…
Coincitentally hardware to play with those types of attack just got commodified
https://www.kickstarter.com/projects/coflynn/chipwhisperer-l...
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#86Would reducing the speed memory is clocked at prevent this?
Yes, it would, as would overvoltage, and reducing the refresh interval. The latter reduces memory subsystem performance, however.
row access counters in memory controller would solve this problem - too many accesses between refresh cycles -> force refresh cycle for that particular row/potentially affected rows
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#87You know, this makes me wonder. If a car manufacturer or a toy company made a product that was found to be unsafe, there would be a recall. If hardware manufacturers make a product that is insecure, will there be a recall? Unfortunately, I suspect that this is a case where the law hasn't caught up with technology.
It's not just insecure, this is memory that doesn't work 100% like memory should.
I use MemTest86+ on every stick of DRAM I buy - if there's even a single error, it goes back as defective. The fact that this memory seems to work for most access patterns doesn't excuse the fact that it is completely broken for others, because good memory should be able to store any data and maintain its integrity for any access pattern.
Unfortunately even MemTest86+ is not exhaustive, as I found out while troubleshooting a very strange issue: a specific file in a specific archive would unpack with corrupted bits (and an "archive damaged" message) on a coworker's computer, but on half a dozen other machines would be fine. A hash of the file matched, so HDD-based corruption was ruled out. His machine passed an overnight run of MemTest86+ perfectly and AFAIK unpacking no other archives would yield corruption. He reported never getting any crashes - but yet, that one file in that archive would fail to unpack correctly.
It would always corrupt in the same strange way. On a whim, I decided to swap the RAM out and the problem went away. Even the "bad" stick seemed to work fine in other machines with the same model of CPU and mobo running the same OS and unpacking the same archive, but with his extremely specific combination of hardware and software, would always fail. That experience taught me that bad RAM can be extremely difficult to troubleshoot.
This isn't like other storage technologies e.g. SSDs where their finite lifespan and sensitivity to access patterns is well-documented. It's a case of claiming to sell memory while giving consumers a close approximation of one that completely breaks in some situations. I think it needs to be treated like the FDIV bug.
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#88Earlier quoted context omitted.
I understood the litigation risk. In an integrated system it's always someone else's fault (DRAM, BIOS, CPU, laptop vendor). IMHO the last integrator (the one selling you the goods) is always the culprit. Why would they fear hardware manufacturers' litigation more than software vendors' ? Especially at such a big company like Google ?
They also don't want to say "DellappLenoHP" laptops could not be attacked and turn out to be wrong. Or maybe they're right but only with factory 2GB modules used between May '11 and July '13. Way too many variables to make any claims that is ethically defensible.
They could specify the detailed system configuration with the CPU, chipset, and DRAM part numbers (including date codes) so others can compare. It's much better than leaving things in the dark completely.
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#89Earlier quoted context omitted.
They were quite cool. From memory, I think one card had some internal startup check that checked to see if its EPROM got marked by the "Black Sunday" countermeasure and then hung itself. The hackers, having a ROM dump and having knowledge of how many clock cycles each instruction took the CPU, knew that it was at ~clock cycle 525 or so that this internal check happened. Knowing that the instruction was a "Branch if e…
Coincitentally hardware to play with those types of attack just got commodified https://www.kickstarter.com/projects/coflynn/chipwhisperer-l... https://www.assembla.com/spaces/chipwhisperer/wiki
Same with the JTAGulator units. 10+ years ago, countermeasures would reprogram the very-difficult-to-desolder TSOP EEPROM on the receiver.
The manufacturers seemed to use an externally accessible JTAG access point to program the receivers in the factory, which was a convenient boon to hackers that didn't even need a screwdriver to reprogram the units through their parallel ports.
Re: Project Zero: Exploiting the DRAM rowhammer bug to gain kernel privileges
#90Earlier quoted context omitted.
Can you get killed as a result of privilege escalation? The law hasn't caught up in part because the potential consequences aren't nearly as dire.
Modern medical technology relies heavily on computers and software. Take an infusion pump for example. Controlled by a microcontroller and using software. Or insulin pumps; and some vendors are actually considering to add Bluetooth to insulin pumps, so that patients using such a pump can check its status on their smartphone (or on the upcomming smart watches). Also you can adjust the infusion rate of an insulin pump…
> Modern medical technology relies heavily on computers and software.
Which is why medical devices should all have ECC memory. And for that matter physical separation between any processor that might run attacker-controlled code and the processor responsible for That Which Must Not Fail.
Product defects like this are foreseeable. If bad memory can cause a medical device to kill someone, the party at fault is the one who made a medical device without sufficient redundancy and error correction that bad memory could cause it to kill someone.