Live data from Hacker News

Show HN: Android 'root' phones via dirtyc0w exploit

gist.github.com

51–60 of 72 posts

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

#51
post #49
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.

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?

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

#52
post #43
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 u…

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

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

#54
post #19

Earlier quoted context omitted.

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

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.

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

#55

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

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

#56
post #24

Earlier quoted context omitted.

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

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?

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

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

#57
post #30

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 !

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

#58
post #41
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).

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

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

#59
post #52
post #43

Earlier quoted context omitted.

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

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.

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

#60
post #58
post #41

Earlier quoted context omitted.

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…

Thank you, this is very insightful.
Post reply on HN