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.
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.
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.
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.
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.
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.
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.
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 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?
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."
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.
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.
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).
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
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 !
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).
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)
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).
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.
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?
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...
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.
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!
71 comments
[ 3.7 ms ] story [ 143 ms ] threadWhat'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.
Thanks!
edit: Apparently SETUID is disabled on Android:
source: https://lwn.net/Articles/609511/also: https://unix.stackexchange.com/a/250806/95938
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.)
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.
I think this would be a "temporary root", rather than something like CF-AutoRoot that gains persistence by modifying the system itself.
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.
I suspect you got much the same back in the microcomputer era. Just look at the various phreaker stuff salvaged from BBSs.
Maybe pseudo-sudo?
https://github.com/timwr/CVE-2016-5195
edit: Correct, I was confusing it with Row Hammer.
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.
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 there is no real answer here. Warn them, and warn them often might be the mitigation.
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...
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.
Hopefully this is where Google's app scanning shines and prevents this exploit from spreading.
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 .
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 !
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.
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)
i trust apps i install from f-droid more than the playstore.
Ah well. I shall have to live with an unrooted S5 for now, unless the rowhammer people come up with something.
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.
Sometimes they do. Samsung was caught adding bloatware that disabled Windows Update: http://arstechnica.com/information-technology/2015/06/samsun...