Dirty Cow

[kennonk]

Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.

http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/

 

[SimLynks]

Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.

http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/

Based upon the early research into this, YES it would appear that this also has widespread affect into the Android Linux Kernel

https://www.nowsecure.com/blog/2016/10/21/dirty-cow-vulnerability-mobile-impact/

https://www.theguardian.com/technol...ow-linux-vulnerability-found-after-nine-years
(Bottom of Article Google confirms Android is susceptible)

PoC Code which would probably need to be slightly refactored for use in Android, but still highly relevant
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs

 

[Scorpius666]

The bug affects the Android Linux kernel. I already tested it, and yes, you can change any file owned by root to whatever you want.

But that doesn't mean you can actually root the phone (that is, gain root access). Maybe it is possible, but I don't think is trivial. The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access. Editing init scripts won't work since they are recreated every time you boot your phone, and after the phone boots, as far as I know, nothing else is executed by root.

I don't mean that it can't be done, maybe there's some file that is executed by root after boot out there that you can modify, but I wouldn't know which one.

 

[KillahKiwi]

The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access.

Doesn't that mean you can install a custom su binary and just execute that as any user?

 

[a___]

This exploit only allows you to replace the content of existing files with their existing mode/permissions, and the way su operates you need the setuid (set-user-ID) bit set in the mode, and from a brief look at the system I wanted to get root on, android doesn't seem to have any setuid binaries.

I'm thinking replacing something like wpa_supplicant could let us execute the payload as root, just disable and re-enable wifi, but I can't seem to get the exploit itself to work at the moment.

On further inspection (at least on this device), wpa_supplicant isn't readable by non-root (which I think the exploit requires). app_process is, but that's an executable I'd prefer not to mess with

Update:
Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.

 

[DP FH]

This exploit only allows you to replace the content of existing files

Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.

 

[julianwi]

The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.

 

[Scorpius666]

Doesn't that mean you can install a custom su binary and just execute that as any user?

You can't create a new file. You can modify an existing file. The su binary needs the setuid bit and there are no files in the Android filesystem with that bit set.

The only way to root a phone with this bug is to modify an executable that will change the owner of the su binary to root and set the setuid bit on this file. This part is trivial and very easy.

The difficult part is to find a binary that will be executed as root after you have booted. If somebody knows any file in /system/bin for example that will be executed as root doing some action on the phone tell me and the phone will be rooted in seconds.

---------- Post added at 11:32 AM ---------- Previous post was at 11:28 AM ----------

Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.

I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.

---------- Post added at 11:35 AM ---------- Previous post was at 11:32 AM ----------

Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.

I'm compiling on the phone using UXTerm, then apt install clang, and then using gcc. It's the quickest way to compile a single .c file on it.

 

[DP FH]

. It's the quickest way to compile a single .c file on it.

I'd like to create a standard Android app that uses jni to run exploit and then roots the device. I can't test on my real phone because I need warranty and Knox counter to 0.

 

[Scorpius666]

Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.

At first try doesn't work for me:

shell@victara:/data/local/tmp $ ./dirtyc0w-mem b6dc0000 b6dc1000

[*] range: b6dc0000-b6dc1000]

[*] getuid = b6f79b18

[*] mmap 0xb6dd5000

[*] exploiting (patch)
./dirtyc0w-mem: failed to execute "su": Permission denied

[*] exploiting (unpatch)

[*] unpatched: uid=2000 (madviseThread)

[*] unpatched: uid=2000 (procselfmemThread)

But I'll modify a little bit to see if I can get it to work.

 

[DP FH]

doesn't work for me.

I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try

 

[Scorpius666]

I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try

I do have the su, in /data/local/tmp, with users permission. The idea is to do a chown root:root and a chmod 4755.

But I know what the problem is. The SHELLCODE in the file is for x86, which seems to be a XOR AX, AX and a RET. I have to do the same for an ARM v7L in THUMB I think...

 

[a___]

Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
<URL>
I'd like to port that to an apk using the ndk, but my pc is too old.

Well that assumes we have a setuid su already, this variant of the exploit won't help us.

The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.

Somehow it did manage to overwrite it, but maybe the reboot and reset are caused by it being read-only and not actually writing the changes to persistent storage.
Will look into /sys/kernel/uevent_helper though, thanks

...
I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.
...

Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs

 

[Scorpius666]

Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs

The thing is all my fsck* files are not readable, only by root, at least in my device. The exploit needs a readable file.

 

[DP FH]

Well that assumes we have a setuid su already, this variant of the exploit won't help us

Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.

 

[a___]

Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.

No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.

 

[Scorpius666]

No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.

I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.

 

[DP FH]

I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.

Strange, on normal x86 works like a charm so something needs to be fixed

 

[Scorpius666]

Strange, on normal x86 works like a charm so something needs to be fixed

Of course it works on x86. If you read the code you'll see that it changes the function getuid() of libc (that is already loaded in memory) to return 0. The x86 su binary uses getuid() to know if it should ask for a password or not. Since getuid() is patched, it doesn't ask a password and spawn a root shell.

So basically for dirtycow-mem to work you need:

• A su binary with setuid root
• That su binary should ask for a password

The Android su binary doesn't ask for a password and doesn't have the setuid root so this exploit won't work.

 

[ajusacav]

hey there

did anyone try the dirtycow-vdso exploit? it works on SELinux (which AOSP uses) and doesn't require a SUID see


github . com/scumjr/dirtycow-vdso