Dirty Cow

Search This thread

SimLynks

Senior Member
Sep 30, 2016
69
133
NYC
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
 
  • Like
Reactions: 5318008 and kennonk

Scorpius666

Senior Member
Apr 19, 2011
53
33
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.
 
  • Like
Reactions: 5318008

a___

New member
Oct 23, 2016
4
5
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.
 
Last edited:

DP FH

Senior Member
Apr 11, 2013
137
29
Apricena
Xiaomi Mi 10T / 10T Pro

julianwi

Senior Member
Jun 13, 2014
78
76
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.
 
  • Like
Reactions: 5318008

Scorpius666

Senior Member
Apr 19, 2011
53
33
Doesn't that mean you can install a custom su binary and just execute that as any user? :confused:

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.
 

Scorpius666

Senior Member
Apr 19, 2011
53
33
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:

Code:
[email protected]:/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.
 

Scorpius666

Senior Member
Apr 19, 2011
53
33
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___

New member
Oct 23, 2016
4
5
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
 

a___

New member
Oct 23, 2016
4
5
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.
 
  • Like
Reactions: DP FH

Scorpius666

Senior Member
Apr 19, 2011
53
33
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.
 
  • Like
Reactions: waliej

Scorpius666

Senior Member
Apr 19, 2011
53
33
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.
 
  • Like
Reactions: DP FH

ajusacav

New member
Oct 23, 2016
1
0
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
 

Top Liked Posts

  • There are no posts matching your filters.
  • 7
    Would you be willing to explain this, no one seems to want to help, just state what they can do, great for them.

    A simple root shell or ability to pull recovery or boot from device is all that's needed, but to get someone who knows how to do it to explain how to do it is impossible.

    Sure, but it is already mid-night in my time zone and the development machines and source codes are not with me right now, I hope I can share it on GitHub in daytime.

    I cann't disclosure my device model, but I can say its specification instead.

    Spec
    SoC: QCOM Snapdragon 430 msm8937
    OS: Android 6.0.1
    Storage: 2GB RAM+16GB eMMC
    External MicroSD card slot, hotpluggable (don't need to take battery out)

    Draft step:
    1. Prepare a MicroSD card with 2 partitions, the first one is exFAT, and the second one is for write(), like "dd" does, my MicroSD 16GB card is partitioned to 512MB(exFAT)+15GB, partitioned by "fdisk" on Mac OSX


    2. Compiled CVW-2016-5195

    3. A "fake-fsck.c" program that is used to replace "/system/bin/fsck_exfat", setresgid()/setresuid() are not needed! because "fsck_exfat" will be ran as root by default, and it is still readable on uid2000 , so contexts of setresgid/setresuid are no longer painful, just focus on the BLOCKS. I will release the source code once it is ready.

    Code:
    It is allowed from[I] scontext=u:r:vold:s0[/I] -> [I] tcontext=u:object_r:block_device:s0[/I]
    [   47.357248] type=1400 audit(1477829349.300:123): avc: granted { read open } for pid=3629 comm="fsck_exfat" path="/dev/block/mmcblk0p27" dev="tmpfs" ino=12129 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file
    [   47.357821] type=1400 audit(1477829349.300:124): avc: granted { read } for pid=3629 comm="fsck_exfat" name="mmcblk0p29" dev="tmpfs" ino=12137 scontext=u:r:vold:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file

    Since the context (I forgot the names) of "fsck_exfat" is only allowed to perform block-level actions, EVEN /data/local/tmp/ won't be writable, so you need to read() the boot/recovery partition and write() to the second partition of microSD card, it is something like "/dev/block/vold/public:166,56" on my device, didn't remember the exact value.

    4. Make it on the Android device
    Code:
    adb push libs/armeabi/fake-fsck /data/local/tmp/fake-fsck 
    adb push libs/armeabi/dirtycow /data/local/tmp/dirtycow
    adb shell chmod 777 /data/local/tmp/fake-fsck 
    adb shell chmod 777 /data/local/tmp/dirtycow
    adb shell /data/local/tmp/dirtycow /system/bin/fsck_exfat  /data/local/tmp/fake-fsck

    This step is finished, don't manually run "/system/bin/fsck_exfat", it is not "run-as"

    5. To let "/system/bin/fsck_exfat"(replaced by "fake-fsck") ran, just insert the MicroSD card prepared on Step 1, the process of a card inserted event is likely to be:
    • Card inserted, the system will read partition table
    • exFAT detected, than perform fsck_exfat before mounting
    • /system/bin/fsck_exfat is ran, this is the trick

    Although the above steps are quite unorganized, but I still hope that can bring some insights to those who are working on it
    7
    OK,

    I achieved root with selinux bypass on a galaxy note 4, marshmallow, arm 32 bit.

    Writing the shellcode was a pain.

    Tomorrow if you want I'll post the full details, I'm too tired now.

    Matteo
    6
    Dirty cow is sufficient to circumvent SEAndroid.
    https://www.redtile.io/security/galaxy
    shows how to get temp root on the galaxy s7 active and arbitrarily change sepolicies.
    6
    Here are my results so far:

    I can start a root shell by overwriting dnsmasq and enabling wifi tethering

    I can start android apps in a different selinux context by modifying seapps_contexts

    Now I'll try patching /sepolicy on the fly to add a super permissive rule
    5
    I assume the debug firmware was a leak from LG or some such thing? In that without it, DC alone wouldn't have been enough to unlock the bootloader?

    dirty cow alone isnt enough to root any phone let alone unlock the BL.. However, it can be used towards root or unlocked BL. With that I mean with dirtycow, you can attack pretty much anything you want..

    for example, you can use dirtycow to say gain access to init and in theory reload an sepolicy to set the device to permissive and/or disable secure boot. You could in theory attack the bootloader or even overwrite it if you find any exploits to use with dirtycow.. it opens the doors for many things.. on the v20 for example we used a modified run as which we used dirtycow to overwrite the existing one to spawn a root shell then used that shell to dirtycow another process which we then used that process to dirtycow atd process which is able to write to the aboot blk file.. we at this point were able to overwrite existing aboot with the debug aboot which was unlocked by default and since it was signed by LG the phone accepted it and disabled secure boot as well as was unlocked and fastboot enabled..

    and the v20 debug firmware was on a us996 v20 that someone was able to buy before it was even launched.. not sure if it was a lg employee or where it originally came from but you can say we got lucked out lol