
Show HN: Android 'root' phones via dirtyc0w exploit - Arinerron
https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6fdfd80
======
bastijn
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.

~~~
Arinerron
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!

~~~
bastijn
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.

~~~
Arinerron
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?

~~~
anilgulecha
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.

~~~
Arinerron
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.

------
edsouza
This is just automating running the exploit from here:

[https://github.com/timwr/CVE-2016-5195](https://github.com/timwr/CVE-2016-5195)

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

------
Arinerron
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
htt​ps://g​oo​.​gl/f​8HdO7, and the script to automate it is here
[https://goo.gl/r2dFia](https://goo.gl/r2dFia) .

~~~
ce4
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://github.com/timwr/CVE-2016-5195)

~~~
pasta
[https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6...](https://gist.github.com/Arinerron/0e99d69d70a778ca13a0087fa6fdfd80)

------
Arinerron
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.

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

~~~
sdrothrock
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.

~~~
daveloyall
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.

~~~
sdrothrock
[http://www.cs.ucr.edu/~zhiyunq/pub/ccs15_root_providers.pdf](http://www.cs.ucr.edu/~zhiyunq/pub/ccs15_root_providers.pdf)

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

Thanks!

~~~
sdrothrock
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. :)

------
w23j
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.

~~~
ferongr
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).

~~~
kuschku
> 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)

~~~
ferongr
Thank you, this is very insightful.

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

------
dep_b
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.

~~~
rmsaksida
> 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...](http://arstechnica.com/information-
technology/2015/06/samsung-silently-disabling-windows-update-on-some-
computers/)

------
guelo
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](https://news.ycombinator.com/item?id=12756006)

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

------
Arinerron
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!

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

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

~~~
fulafel
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).

------
qwertyuiop924
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.

~~~
sp332
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...](http://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-
root-android-phones-is-now-a-thing/)

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

~~~
rkeene2
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 !

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

------
bitmapbrother
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.

~~~
ommunist
Forgive my ignorance, how this is possible on iOS?

~~~
lnx01
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.

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

~~~
baq
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.

