Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Android 'root' phones via dirtyc0w exploit

gist.github.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#41

Post by ferongr »

w23j wrote: post #38

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.

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

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#42

Post by userbinator »

Arinerron wrote: post #21
bastijn wrote: post #11

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…

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 app…

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.

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#43

Post by yasth »

w23j wrote: post #38

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.

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

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#45

Post by pja »

w23j wrote: post #38

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.

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.

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#46

Post by omribahumi »

therein wrote: post #31
omribahumi wrote: post #18

Earlier quoted context omitted.

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

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#47

Post by 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.

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#48

Post by rmsaksida »

dep_b wrote: post #47

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 thei…

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

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#49

Post by baq »

w23j wrote: post #38

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.

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.

Re: Show HN: Android 'root' phones via dirtyc0w exploit

#50

Post by baq »

pbhjpbhj wrote: post #39
lnx01 wrote: post #37

Earlier quoted context omitted.

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.
Post reply on HN