Yeah. Most teens don't have dreams about code, but I do. I fall asleep thinking about some bug, and wake uo with a solution. Unfortunately, I sometimes forget it :P
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!
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
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?
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.
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."
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.
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.
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.
