Caution: Dirtycow can do persistant modifations on readonly files

[McBuffalo]

I have read [ https://forum.xda-developers.com/showpost.php?p=70311089&postcount=44 ] one xda-user used dirtycow to modify file /system/etc/fonts.xml and modifications was there after boot. His phone is "Moto G 2014 with stock Marshmallow"

I encountered this with Samsung Xcover 3 (gf388). I don't know how to reproduce it, but now I have /system/bin/wpa_supplicant permanently* broken with random data (I was just testing dirtycow and wpa_supplicant was ~biggest binary there). I haven't yet got root shell and /system-partition has been always mounted read only.

[EDIT] Android 4.3 Linux version 3.0.31-2429075 (dpi@DELL135) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT Wed Apr 30 18:49:01 KST 2014 [ro.build.date]: [Wed Apr 30 18:55:06 KST 2014] [ro.build.description]: [m0xx-user 4.3 JSS15J I9300XXUGND5 release-keys]

*) until reflash

So beware: Dirtycow will eat your children!

[timwr]

What version of Android? I've bricked a phone or two from this but never >= 6.0. Sometimes you can re-flash them :)

[rosehgal]

@timwr is it possible to wrap the code in android apk and ask apk to execute run-as, because that will allow any one child process to run-as temporal root. I am also curious to now how can i actually execute run-as from within the apk. Its the part of my Masters thesis. Will count towards a big help.

[timwr]

Even without SELinux you can't execute /system/bin/run-as if you're not shell (2000) or root: -rwxr-x--- 1 root shell u:object_r:runas_exec:s0 17944 2009-01-01 03:00 /system/bin/run-as APKs have a uid > 10000 but they can overwrite other files in /system/bin, /system/lib, or shared pages in /proc/self/maps e.g vdso.

[rosehgal]

@timwr that means i can overwrite /system/lib/libc.so with my libc.so and when any function call is say fork() by any root process then the follwoing exploit will turn on.. is this sort of stuff possible ?

[McBuffalo]

I added more information about phone to the first post.

I also reflashed stock firmware and got clean system.

[markostamcar]

Sorry to bump this old thread, but since you mention dirtycow-ing /system/bin/wpa_supplicant:

I wanted to write a one-click app to grab /data/misc/wifi/wpa_supplicant.conf from the device without permanently rooting it. Targeting /system/bin/wpa_supplicant made sense as I can: 1. make a backup copy of wpa_supplicant, 2. turn WiFi off, 3. dirtycow a simple binary that copies wpa_supplicant.conf to /sdcard/, 4. turn WiFi on to have my new binary executed in the right context, 5. turn WiFi off and dirtycow the original wpa_supplicant back.

I did, however, during my experiments, manage to corrupt the wpa_supplicant binary just like you did and that got me a bit nervous - I really do not want to break WiFi functionality on the target device. But then I noticed p2p_supplicant - it is used in addition to wpa_supplicant for WiFi Direct (rarely used) and I can mess with it and it greatly reduces the risk of making users unhappy if it breaks.

So I can confirm that (at least on my device) dirtycow will with high probability make permanent changes to the read-only filesystem! It happens even with the so-called "dirtycow-mem.c".

-- (Added 2 weeks later:) Just a tip, you might want to combine dirtycow with the idea of patching dalvik-cache - see: https://www.nowsecure.com/blog/2015/06/16/remote-code-execution-as-system-user-on-samsung-phones/ Source code at: https://github.com/nowsecure/samsung-ime-rce-poc/issues/5