Slashdot Mirror
Rowhammer Attack Can Now Root Android Devices (softpedia.com)
An anonymous reader writes from a report via Softpedia: Researchers have discovered a method to use the Rowhammer RAM attack for rooting Android devices. For their research paper, called Drammer: Deterministic Rowhammer Attacks on Mobile Platforms, researchers tested and found multiple smartphone models to be vulnerable to their attack. The list includes LG Nexus (4, 5, 5X), LG G4, Motorola Moto G (2013 and 2014), One Plus One, HTC Desire 510, Lenovo K3 Note, Xiaomi Mi 4i, and Samsung Galaxy (S4, S5, and S6) devices. Researchers estimate that millions of Android users might be vulnerable. The research team says the Drammer attack has far more wide-reaching implications than just Android, being able to exploit any device running on ARM chips. In the past, researchers have tested the Rowhammer attack against DDR3 and DDR4 memory cards, weaponized it via JavaScript, took over PCs via Microsoft Edge, and hijacked Linux virtual machines. There's an app to test if your phone is vulnerable to this attack. "Rowhammer is an unintended side effect in dynamic random-access memory (DRAM) that causes memory cells to leak their charges and interact electrically between themselves, possibly altering the contents of nearby memory rows that were not addressed in the original memory access," according to Wikipedia. "This circumvention of the isolation between DRAM memory cells results from the high cell density in modern DRAM, and can be triggered by specially crafted memory access patterns that rapidly activate the same memory rows numerous times."
One of the simplest existing known attacks involves creating an 8MB TypedArray object in JavaScript. This gives you a contiguous virtual address range, which allows you to generate 9 addresses that will be aliased to the same cache line and therefore where 9 sequential writes will trigger an eviction and a write back to RAM. What made this attack now work on mobile devices?
I am TheRaven on Soylent News
Of course this is a terrible bug for most.
On the other hand it would be awesome if one could incorporate this attack into an app that roots the device without needing to connect it to a PC first.
You Android device is ROOTED :-(
A bunch of pasty faced sad sack nerds sitting in a basement want to sound cool and tough, like they've just done a tour in 'Nam. So they don't say "enabled" by javascript, no no no, its "weaponised" with "attack vectors" instead of flaws or holes. Its just so lame and wannabe.
Lucky I upgra
Does anybody know if this affects Amazon Kindle devices since they are an Android Fork?
time to implement ECC everywhere, period !
it's not like ram is expensive anymore
Can't wait until it's up on XDA Developers for the S5 from AT&T, which so far hasn't been able to be rooted, and is the phone my work gave me. Sure it's a free phone and it's a work phone... But I wanna put a different ROM on it, dammit.
This sig isn't original enough, it's time to come up with something witty...
No problem with my Asus Zenfone2 with an Intel chip! (I hope)
"Science will win because it works." - Stephen Hawking
This is just another reason why we need to migrate away from DRAM. It's simply at a fundamental level too easy to exploit this way. We need to move to non-volitile memory, which is more power efficient anyway. Hopefully within a few more years the tech will be there.... I'm most excited about the carbon nanotubes, myself.
They provided the direct link to the apk file. Scroll down in the README.md displayed on the github link to the heading "Android GUI app" found here. The first line of the paragraph has the phrase "Android app" as a link to the drammer.apk file. You can use this to sideload onto your device and perform the check. They also tried to provide a link to the Google Play page for the app in that section of the doc, however it looks like Google disabled it as against the TOS (link now goes to a 404 page).
All that said, this is probably one of those apps you'll want to first read the source and see for yourself what it's doing, then install the Android NDK on a PC to compile it; from there sideload the apk you built. This way you can at least be a little more certain of the build to make sure that it only does exactly what the code says it should...instead of trusting someone else's build to not have any added features
Shouldn't they have called it DRAMP?
So I have to jump through hoops to try to root my S6 and end up giving up and restoring a backup... but this thing can drive by root it? wtf
I hope you're just being sarcastic, but in case you're not, ...
- This is a hardware issue, not a programming language problem
- Rust helps to prevent programming bugs with memory, like dangling/null pointers, buffer overflows etc. But it has control over the memory layout, which is a crucial requirement in implementing a row hammer attack, so a row hammer attack with Rust would likely be very suitable for implementing such an attack
- Even if there was a programming language that prevented this by doing some memory layout randomization or similar, it would also lose performance due to non-contiguous memory (prefetching will not work and there will be cache misses), and thus it also would kill the battery life
- Even if ignoring the points above, it would require a massive amount of work to move away from JavaScript on web pages
- We would also require the OS, including the kernel, written in such language (which probably would not be possible, since there would be an abstraction of memory, which doesn't play nice with many device drivers etc.)
If the AI's are created in any kind of evolutionary manner, then almost certainly yes. It's happened with hardware design before.
This Space Intentionally Left Blank
They are crackers not researchers damn!
What has their skin colour got to do with it?
Also, the correct term is "economically-disadvantaged caucasians".
Can we stop calling these fucktards researchers already? They are crackers not researchers damn!
Yeah, I mean, researchers explain their methodology and publish papers about it! These are just the dumbest criminal hackers that put their names on some paper they published! Can't wait until they go to jail for their criminal deeds which they are obviously waiting do in the future! -_-
Anons need not reply. Questions end with a question mark.
Gee, thanks.
There are lots of people who are stuck on unrootable devices and could really use this.
but RAM makers have no incentive to fix it
Actually, they do. They can market lower-density, more-expensive-to-manufacture RAM which has spacing or other "rowhammer-protecting design elements" between rows for use in "high- but-not-quite-military-grade-security" applications.
For example, if off-the-shelf equipment would have been approved for a high-security application but for the vulnerability to rowhammer and similar attacks then the product vendor can substitute the more expensive, lower-density, more-secure RAM and sell his product to the customer rather than lose the sale entirely.
As for military-grade applications, I'm not going to pretend to know what their requirements are or how to address them.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Theoretically you could relocate memory periodically in a system like Rust (or Java). This could be done so that the high level doesn't realize it has happened. It might have a fairly heavy performance cost, depending on how frequently the relocations are done and how you detect when you should do them. (scoreboard vs static analysis)
I could write a very simple language/environment where rowhammer is essentially impossible. But it would be very slow. Obvious example is that every address is looked up on a hash table to find the physical address. The application cannot see this hidden hash table, it would allow a byte granularity to relocation instead of a page granularity. It would was a tremendous amount of memory and be very slow. (basically memory layout randomization)
JavaScript itself doesn't necessarily need to be replaced. Replacing it with a similar implementation of Rust doesn't make rowhammer go away. Working around the issue is possible in JS, Rust, Java, Haskell, and a few others. Not practical to work-around in C, but theoretically possible.
If you use SRAM instead of DRAM, there is no performance penalty for layout randomization. Of course, SRAM doesn't have the issue with rowhammer either.
“Common sense is not so common.” — Voltaire
LOL, "I asked some crack heads to house sit for me while I'm out of town for a few weeks. I figure if there was a problem they would stop smoking crack and tell me."
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
Redesigning the memory controller or DRAM is enough to solve the problem; force out of order refreshes on rows adjacent to continuously accessed rows. This is now called Target Row Refresh.
Apparently Intel patented their fix on Oct 31, 2013... the exact same day that Nexus 5 shipped in the US:
https://www.google.com/patents...
Glad to see the industry came together to protect consumers!