Using Rowhammer bitflips to root Android phones

That would be very nice indeed. And on a laptop that comes in less than €2k also would be doubly nice.

Touché.

Does ECC memory make this harder to pull off? I was under the impression that ECC memory does not mitigate rowhammer although it may make it harder[1].

> Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word.

[1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation

If you want to leverage Rowhammer to get ECC everywhere, don't root phones; figure out how to crack into a media stream you shouldn't have access to, like a Netflix stream or a Bluray rip. Which may very well incorporate rooting phones. But that'll get the industry forces screaming for ECC everywhere (and per other threads, whatever else it takes to make hardware proof against Rowhammer) far more than merely rooting, and they'll scream for it for all hardware. No point in protecting Blurays if the cheapest hardware is what rips the most easily.

Proofing hardware against Rowhammer is still necessary even if it does happen to help DRM. It is not possible to write secure code of any kind in an environment where Rowhammer can be performed. The casual dismissiveness the industry seems to have about this problem really surprises me... per the article we all just read, this at least threatens to become a Heartbleed-class problem at some point, but will make Heartbleed remediation look like a walk in the park by comparison. Hardware diversity generally protects us, but there are places where there isn't as much diversity, such as phones, where this could become a massive problem.

Hmm, so the purpose of memory scrambling is to avoid excessive current swings on the data bus, because they have some kind of undesirable effect on the voltage regulator. I wonder if the result of such current swings is just excessive EMI or power consumption, or if the supply can actually go out of regulation. If you know the scrambling algorithm then you can generate those current swings intentionally...

Most likely related to strict FCC regulations regarding the mobile transceivers.

And it's always been done this way, old "dumb phones" have always been closed proprietary blobs.

You don't, if you care enough to buy a phone where that's possible. Any Nexus device can be reflashed to a custom Android build for example. Of course you void your warranty that way.

What you're really asking is why is there no root shell by default on all phones, and simply posing the question also answers it - it's a phone, there's zero demand for messing about with terminal emulators on a phone. If you say, but I'd like to install apps as root, the problem is such apps could break the phone in arbitrary ways like by infecting it with malware/adware/spyware that then can't be uninstalled. Modern operating systems are very much designed to limit what apps can do to avoid the nightmare that desktop OS's turned into, where people are afraid of installing apps in case something goes wrong. For better or worse you can install apps on Android/iOS without much fear, which is one reason people do it so much: you can always remove the app again if it's trouble.

Android is pretty customisable and has lots of permissions anyway. There are very few things you can't do if you don't have a carrier-locked phone. So supporting apps with root access would vastly worsen the malware situation in order to satisfy a tiny number of geeks who like editing config files: a very bad tradeoff.

But hey, Android is open source, so if you think I'm wrong go ahead and make money selling phones with root access.

This isn't about you, the consumer, getting root access. It's about a piece of code running on your phone (i.e. maybe part of an app with restricted permissions) getting root access.

Because the trust model on phones is different.

On old UNIX mainframes the trust model had 2 kinds of actors:

- System administrators

- Users

The biggest security concern was one user getting access to the files of another user on the same system. The sysadmin decided which applications to trust (and most of them were either opensource or made by big companies, so we didn't have to worry about application developers doing nasty things). As a result, applications just ran with all the permissions of the user who started them. They could do anything that the user themselves were allowed to do, like read all your files, open a network connection and send your secrets out over the internet. But so long as users didn't run any dodgy programs it was (mostly) fine.

All modern desktop operating systems inherit that system. But over the last couple decades three things have changed:

- Computers got so cheap that now everyone has their own

- There are more apps than ever, and some of them are malicious

- There aren't enough sysadmins to save grandma

Modern phones we have a much better security model, which they inherited from the web. There are two changes:

- Multiuser support is gone at an application level.

- Apps are sandboxed from one another to protect you and your data from malicious apps. The way they do that is by isolating each app on the phone so no app can read&write to any of the data owned by another app.

For example, if you use google docs then by necessity you have to trust the docs app with your documents. But thats it! The google docs app doesn't get to access to your facebook login information. And the facebook app doesn't have access to your google account. If you had equivalent native apps on your desktop, these apps would be able to read one another's files!

But rooting your phone (at least partially) ruins all that! Rooting (by definition!) gives some 3rd party apps the capacity to access data stored by other apps on your device, which ruins the phone's security model.

The reason why some manufacturers (like apple) take a hardline stance against rooting is that if rooting your phone was easy, some app developers would undoubtably decide they'll only function on rooted devices. (This happens on android today for wifi sniffers and stuff like that.) If enough apps do that, the manufacturers will feel pressure to make it easy to disable app sandboxing, which will result in more and more apps wanting "Full permissions on your phone". People will mash "yes" on the install box (nobody reads that stuff anyway) and before you know it there'll be malware on your phone reading your email and threatening to send porn to your boss on your behalf if you don't pay up. DDoS attacks will come from phones, and will cripple the mobile network. And to fix all that norton will release an android version which will start scanning your phone for viruses at the worst possible moment of that show you like on netflix.

And that is why rooting your phone is hard.

because nobody dares publishing anything on Android at Google without going past legal, pr and recently the founder

Presumably you're asking why you're hearing about it before the fix is out. Perhaps Google is trying to apply public pressure to the manufacturers/carriers to actually update their devices since they have a habit of not pushing critical security updates very quickly.

Because the existence of this exploit was already publicly known, as you can see in the many links in that article. That statement doesn't have any new information for people who want to break into your phone.

nullc makes a similar comment below.

I had thought this was too obvious to bother pointing out, but no, root exploits are not a good thing. The reason phones use kernel sandboxing is to allow users to install apps and have confidence the permissions granted mean something. A root exploit means any app or update you install may turn the phone into spyware, a portable bug-in-your-pocket.

The number of users who care about that is measured in billions (all phone users). The number of phone users who care about getting a root shell for their own use is vanishingly small, especially as people who care about that buy phones like the Nexus that have unlocked bootloaders anyway.

So no - this sort of exploit is pretty damn bad. The number of people hurt is multiple orders of magnitude higher than the number of people "helped", where that "help" is extremely tenuous anyway.

Not just because of not getting enough chips. Sometimes it is plain hedging against potential flaws, or supply chain failures.

Doubtful. A malicious app could always programatically write the attacking binary after it has been installed. At that point, you no longer have serious performance requirements, so you can make the functionality as obfuscated as necessary. Not to mention the possibility of self modifying code, or downloading the payload from the internet.

I think dynamic analysis would be more useful.

>a human (at Google) could override

you cant be serious, google is not paying 200K for developers to play with individual cases of consumer/dev support. You cant even get Human support from google when you make >$100K a month in adsense/YT.

Here's a dynamic approach to stopping rowhammer: http://www.openwall.com/lists/kernel-hardening/2016/10/27/18

Root is to Android what jailbreak is to iOS, and the proof of concept[0] that was released is exactly that rooting tool.

https://play.google.com/store/apps/details?id=org.iseclab.dr...

It's clever because you aren't a memory design or test engineer. This type of problem has been known and tested for since shortly after DRAM was invented.

E.g. here's a 1977 databook from Mostek, at the time the premier DRAM manufacturer: https://archive.org/stream/bitsavers_mostekdataryProducts_17...

Look at these tests in particular:

   Adjacent Row Disturb Refresh
   Column Disturb
   Pattern Sensitivity

Look at the details of the column disturb test:

Column is written with an all ones data pattern an "0" is then written into row of the column 100 times followed by reading all other bits of the column and checking each bit for a logic "1" output. Row of the column is then rewritten to a "1" and the procedure is repeated for rows 1,2,3, ... 63 of the column under test. The entire procedure is then repeated for columns 1-63.

That particular test step is only repeated 100 times, because it's a production test and short test time is critical. You can bet that in design verification the chip was characterized a lot more thoroughly.

The downside of increasing memory sizes over the decades (now literally billions of bits in a single chip rather than thousands) is reduced design margins. So we get rowhammer.

You can bet that rowhammer did not come as any surprise to key engineers at the DRAM manufacturers. They just didn't take it very seriously as a possible real world problem, because the access patterns required to cause it are atypical from those of "normal" operation.