Show HN: Android 'root' phones via dirtyc0w exploit | Hacker News Reader

Show HN: Android 'root' phones via dirtyc0w exploit

gist.github.com

143 pointsArinerron67 comments

I wonder how many people carelessly run a script that downloads, builds, and executed something with root access. If that zip gets compromised (i.e. The source means harm) there is no end to the pain a careless user can endure. It is like blindly copying and running shell commands you don't understand with sudo rights.

My intention is not to offend the author by the way :). It is to remind people to understand these kind of scripts and their risks before you run them.

That is really true. Any solution you propose? I mean, it is all open source, but if the author of the PoC repository were to put malicious code into the file, how would we know before reading the source?

Do you think I should host the file somewhere I trust, and make it check the hash of the downloaded file from a different to ensure it isn't compromised? My worry then is, what if the hash was compromised too?

I appreciate your response. Thanks!

I think it all starts with educating the careless. Remind them of the risks so in due time they learn to think before they act. Do you have a responsibility as the provider of the script? I do not know, as a true hero you could put a statement on the top of your readme. Like a warning message. One step ahead you can become an even greater hero and host the zip yourself on a secure source. However, this places the burden of maintenance to you which is something which you might not like. In addition it brings the question of ownership.\

I think there is no real answer here. Warn them, and warn them often might be the mitigation.

Thanks! What kind of warning message would you suggest? A "the exploit might be compromised" message, a "verify your download with this hash" message, or something else?

One thing you can do is simply fork the repo, and use your repo as the path in the script. So you're not at the mercy of upstream author's changes.

Thanks, I'll do that. One problem though is that I've already published the script here, and migrating to a new repository would leave everyone with a dead link, etc. I could post the script in the fork too, though.

"Careful. Running scripts from unidentified sources can comprimise your device. Never copy and paste something directly from an untrusted source to an executable context. Never ever."

That should do the job.

More good reads on why you don't want to do this: http://www.ush.it/team/ascii/hack-tricks_253C_CCC2008/wysinw...

but if the author of the PoC repository were to put malicious code into the file, how would we know before reading the source?

You might not know but there are probably quite a few who do analyse these things and would "blow the whistle" if they found something amiss.

Thus, if you're really unsure you can wait a short while before using it, to see others' experiences first. In general, the same principle goes for warez and any other unofficial, reputation-driven community where there is no central authority.

If you wanted to be absolutely "safe" you would not be wanting to root anyway... it's risky and I'd say that's even part of the fun for those who do.

From looking at the script and the makefile : you don't need to be root

Dirtycow is a vulnerability that can be exploited to give privilege escalation. So no the script doesn't start running as root - but it aims to get there.

not much different than any app store, which not even the author can validate the binary wasn't changed

This is just automating running the exploit from here:

https://github.com/timwr/CVE-2016-5195

This would actually be a more appropriate URL for the story.

I put 'root' in quotes, because technically, it isn't rooting. However, it creates a binary called 'run-as' that can execute packages as root. Not sure what the right term would be in this case.

Well if you can run any executable as root, that sure counts as rooting in my book.

The advantage I see here is that you don't have to actually root your phone, which means that apps/games that check for root access would continue to work normally.

I've always wondered: what exactly are they checking for?

What's the difference between "I can become the root user on my phone whenever I want" and "My phone is rooted"?

Note: I'm asking as a GNU/Linux user, not as a phone user.

http://www.cs.ucr.edu/~zhiyunq/pub/ccs15_root_providers.pdf

2015-08-20. The document describes analysis performed on those apps which root your phone for you.

Thanks!

No problem! I don't do Android development of any kind and didn't trust my ability to properly explain it, but it's an interesting paper. :)

Sure, but as soon as it's patched out, you're back to no root.

Maybe I'm missing something here, but what stops you from putting a setuid "su" binary and keeping the root access, even if the kernel is upgraded?

You're root running in a limited selinux context.

I'm assuming that's because of the Android security model, rather than a limitation of the exploit itself?

edit: Apparently SETUID is disabled on Android:

  ... using kernel features that help block privilege escalation (e.g. NOSUID, NO_NEW_PRIVS).

source: https://lwn.net/Articles/609511/

also: https://unix.stackexchange.com/a/250806/95938

Are you saying that on Android, you can achieve UID=0 via this exploit, but still not write to anywhere important on the device?

What are these different "methods" listed in the table here?

https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs

Can one of those methods allow me to write to some file in /etc? (Which is enough to grant me the access I want, unless selinux is just MAGIC.)

SELinux can still prevent you (even if you are `$UID=0`) from performing an operation such as writing to a file under `/etc`.

You would need to be able to `setenforce 0 `. A properly configured SELinux context can prevent you from doing that however we are starting to finally see some reports of dirtyc0w successfuly leading to `SELinux status: permissive` and permanent root.

A (somewhat cringeworthy) thread on how to gain persistence via this exploit is at https://github.com/timwr/CVE-2016-5195/issues/9

I think this would be a "temporary root", rather than something like CF-AutoRoot that gains persistence by modifying the system itself.

It's painful to read. Only one person in that thread appears to know what SELinux actually does, and nobody has mentioned the fact that SELinux was explicitly designed to make a root privesc contained.

The ironic part is that since DirtyCOW is a kernel bug they could probably modify the exploit to disable SELinux from inside the kernel (or load a module that disables SELinux). But they're just trying to use the PoC as the only thing you can get from the exploit.

Welcome to the world of phone firmware modding.

I suspect you got much the same back in the microcomputer era. Just look at the various phreaker stuff salvaged from BBSs.

Well at least these github repos and gists are an improvement beyond "here, download this .apk from megaupload and install it!"

> Not sure what the right term would be in this case.

Maybe pseudo-sudo?

For those who didn't see it:

I didn't write this exploit, I just wrote this script that automates the exploit. The repository with the actual exploit is here https://goo.gl/f8HdO7, and the script to automate it is here https://goo.gl/r2dFia .

The first goo.gl link is dead for me... Care to give the real link instead of a shortened URL? Edit as noted elsewhere, should be https://github.com/timwr/CVE-2016-5195

https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6...

So I have a Galaxy Nexus, which does not get OS Updates anymore (Android 4.3 at the moment).

Do I understand correctly that vulnerabilities like this one mean I do not have any protection when I install an App on my phone? I mean the Android permissions system is useless, when any App can just use an exploit to get root isn't it?

Sorry for the beginner question, I am just hoping I am missing something.

That's exactly it, yes, if your phone is vulnerable.

In theory, as long as you don't install apps from third party sources you would be safe. Google does security tests on apps uploaded to the Play Store (don't know how effective they are though).

> don't know how effective they are though

They’re basically useless – they run them on actual devices, and if you use network access you are run through a VPN to ensure you don’t notice you’re running on Google devices from the IP, but it’s still easy to change the functionality depending on if you run on their servers or not.

It’s the old sandbox issue – they can’t statically analyze everything the program might do, and you can always find out if you’re in a sandbox one way or another.

Android antivirus scanners are even worse, though – AVG actually runs them in an emulator that reports itself as Nexus 4 on Marshmallow running on armv7 but is only able to load x86_64 libraries, and they allow network access without any proxying, so you see some AVG IP connect to your servers repeatedly.

(I had a bug in one of my apps that only manifested itself when running in such a sandbox, and which would be reported to my crash reporting service, which gave me a lot of insight into this)

Thank you, this is very insightful.

The good/bad news is that you were already plenty vulnerable. Also they wouldn't need an app to be installed, all they need is to force an app to use (or induce you to say click on a link and use) the already very exploitable webview renderer to open up a webpage. This just simplifies getting root once they have some control, but before this they could have compromised your device, and all this does is simplify the utilization of it (because now instead of a kit of solutions to get root malware can use one a do all hack).

But i can avoid that by only using Chrome for browsing, can't I?

Technically, yes, but considering you can now root Android devices only with DRAMMER, it might even be possible to do the same with Rowhammer.js in the future.

Pretty much. This is one of the reasons people install CyanogenMod on their phones: to get security updates to devices that the supplier has stopped supporting.

which shows how "just don't install 3rd party" argument is pure noxious bs.

i trust apps i install from f-droid more than the playstore.

if the phone's browser has a remote execution exploit that allows for dirtycow to be run, the phone isn't yours anymore; it only takes one infected webpage or a driveby malware containing ad on a popular page to get there. i don't know if the browser gets updates.

My impression was that by only using Mobile Chrome for browsing (which gets updates through the play store), I was at least save from being infected by surfing the web. Is that correct?

For those on CyanogenMod: patch for Dirty COW is about to hit the nightly releases - https://review.cyanogenmod.org/#/q/19be0eaffa3ac7d8eb6784ad9...

I can't help but think what would've happened if it were Microsoft that would have security problems of this scale all of the time while essentially blocking users from getting the updates to fix it. And then there's the manufacturers abandoning their hardware often directly after release.

The angry mob would probably bury them alive...

Sure, we can blame carriers, manufacturers and hardware suppliers for having their own policies, but this is the same for your average Windows laptop minus the carriers. Bundled themes and crapware from Sony, Lenovo or Dell never stopped Windows from updating.

> Sure, we can blame carriers, manufacturers and hardware suppliers for having their own policies, but this is the same for your average Windows laptop minus the carriers. Bundled themes and crapware from Sony, Lenovo or Dell never stopped Windows from updating.

Sometimes they do. Samsung was caught adding bloatware that disabled Windows Update: http://arstechnica.com/information-technology/2015/06/samsun...

This is an Android exploit for the Linux privilege escalation bug made public a few days ago, discussed here https://news.ycombinator.com/item?id=12756006

Hopefully this is where Google's app scanning shines and prevents this exploit from spreading.

Okay, sorry guys. I know it's broken right now. The problem is that wget and unzip commands aren't being used properly. I can't fix it on my phone, because the editor isn't working. I won't have computer access till tonight (it's 4PM here, and I'm at school). Really sorry about the delay!

Okay, should be working now. If you have any issues, feel free to comment them here: https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6...

Good thinking! I wonder if it will get patched soon enough

The fix is out, but as always for nearly all Android users, they will remain vulnerable until they upgrade their device (but then they will have new unpatched vulnerabilities).

Now if only it was permanant...

Ah well. I shall have to live with an unrooted S5 for now, unless the rowhammer people come up with something.

I tried it on my S6 and got nothing. I had to turn the aggressiveness down to minimum or it died immediately. The researchers tried two S5's and got root on one of them, so it might be worth a shot. http://arstechnica.com/security/2016/10/using-rowhammer-bitf...

Is it still possible, when you cannot mount your /system partition as rw, because of well... permissions?

I'm not sure if they've made it more difficult in a while -- they disabled mounting /system read-write but I was still able to copy the block device to another host, modify it, and copy the modifications back. At one point they disabled opening the block device (which was a partition) read-write so I had to open the containing block device (which was the whole disk) read-write and add an offset.

ChromeOS uses dm-verity to prevent this from being an issue, but I'm not sure Android does -- so you should be able to flip some bits on disk without being noticed !

What's the story so far? Is this patched in upstream yet? How serious is this bug in general?

Technically, this is not specific to Android phones. It's a hardware flaw and also possible on iOS.

edit: Correct, I was confusing it with Row Hammer.

Forgive my ignorance, how this is possible on iOS?

Rowhammer rapidly flips bits in RAM. The bits that are rapidly flipped are chosen for their proximity to the physical transistors which store the UID. By flipping the bit near the transistors storing the UID very quickly, it's possible to induce a bit flips in the UID value itself and gain root access. This is a flaw inherent to DRAM, and it completely OS independent. It's a hardware level exploit.

Wow, first I've heard of that one - someones a smart cookie to come up with that, props.

the comments here say that engineers who were developing first DRAMs knew about this since the very beginning and there are actually qualification tests for the hardware. the problem is that capacities got too large to test effectively.

Thank you for the explanation. But will it not disable automatic updates, and AppStore functionality, since UID will loose its integrity?

I think you're confusing this with the DrK KASLR bypass using TSX that was also on the frontpage recently. This is specifically a Linux bug, and isn't applicable to iOS.

You're mixing that up with rowhammer. The exploit that this article is about is a bug in the Linux kernel.

Reply on news.ycombinator.com