Dirty COW

Message

Bigun · Post by **Bigun** » Fri Oct 21, 2016 12:34 pm

Article

CVE-2016-5195

"A race condition was found in the way the Linux kernel's memory subsystem handled the copy-on-write (COW) breakage of private read-only memory mappings," reads the website dedicated to Dirty COW.

Is this being worked on?

linlz · Post by **linlz** » Fri Oct 21, 2016 2:52 pm

I didnt effect my gentoo system. But im running hardened kernel so maybe it works if you dont have hardend your system.
So give it a try to see if it affects your system.
Here is the link:
https://gist.github.com/rverton/e9d4ff6 ... 9df083c679

The instructions are in the top. I didnt make this just fyi.
I could exploit my ubuntu 16.04 system before the last kernel update, but when i rebooted to the new kernel it didnt work anymore.

ct85711 · Post by **ct85711** » Fri Oct 21, 2016 3:41 pm

well, if you are interested on following the bug tracker for this, here's the link to the bug 597624.
Now as far as the patches being ported to all the older versions of the kernel, I couldn't say on which version will get the patch. From what it is looking like in our bug tracker, gentoo-sources-4.7.9 appears to have the patch. Otherwise, it sounds like 4.8.3 also has the patch (but that version isn't available in the tree as of when I last checked, as of a couple minutes ago).

For me, it seems I get to go update my kernel version later on (running like 4.3.6 or so). Who knows, I may just wait til the 4.9 series comes out and do it then. As either way I see it, this issue only has low risk when you need an app to run on the system to trigger it and if someone gets into my system, it's compromised either way.

JuNix · Post by **JuNix** » Fri Oct 21, 2016 3:49 pm

I tried the proof of concept on my stable Gentoo system running gentoo-sources (Linux flatline 4.4.21-gentoo #1 SMP PREEMPT Tue Oct 11 14:23:47 BST 2016 x86_64 Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz GenuineIntel GNU/Linux), and my unpriveledged user managed to write to a read-only root owned file.

Code: Select all

johnh@flatline ~ $ su -
Password: 
flatline ~ # date > /tmp/foo
flatline ~ # chmod 0404 /tmp/foo
flatline ~ # logout
johnh@flatline ~ $ ls -l /tmp/foo
-r-----r-- 1 root root 29 Oct 21 16:47 /tmp/foo
johnh@flatline ~ $ cat /tmp/foo
Fri 21 Oct 16:47:17 BST 2016
johnh@flatline ~ $ ./dirtcow /tmp/foo Mooooo!
mmap 2d5e6000

^C
johnh@flatline ~ $ cat /tmp/foo
Mooooo!Oct 16:47:17 BST 2016
johnh@flatline ~ $

Website · Post by **Zucca** » Fri Oct 21, 2016 4:29 pm

That's pretty nasty. Especially on those who run shell services.

eccerr0r · Post by **eccerr0r** » Fri Oct 21, 2016 5:30 pm

Backported that commit to my gentoo-sources-4.0.5 kernel :o

Compiling... now if only my isp stopped hating github for the test program.

I really should just update to a newer kernel, since I touched mm.h it recompiled just about everything anyway.

[EDIT] Looks like there's a massive DNS DDoS currently happening that's hurting lookup for github. Is this a coincidence or we're really screwed...

[EDIT 2] Linus's git commit seems to have prevented the corruption... Looks good.
Now I need to update all the rest of my machines that are not network facing.

[Edit 3] This looks like it's platform agnostic despite script kiddie rootshell code was added for x86, amd64
Indeed this is big. I wonder if I can go root my android phone now without needing to do anything special... just need a cross compiler...

Bigun · Post by **Bigun** » Fri Oct 21, 2016 7:24 pm

eccerr0r wrote:[Edit 3] This looks like it's platform agnostic despite script kiddie rootshell code was added for x86, amd64
Indeed this is big. I wonder if I can go root my android phone now without needing to do anything special... just need a cross compiler...

miket · Post by **miket** » Fri Oct 21, 2016 7:52 pm

eccerr0r wrote:I wonder if I can go root my android phone now without needing to do anything special... just need a cross compiler...

You'd still have a problem. Nothing here tells you how they made the exploit-causing payload. There are two clues: 1. there are different versions for 64 and 32 bit and the 64-bit version is longer, and 2) they pad it with 0x90, which, as I recall, is the 8086 opcode for NOP. All this means that the exploit code is instruction-set specific.

They don't give a payload for ARM--if indeed a single payload would suffice. There are more flavors of ARM object code than there are for x86, after all! (Combinations of word length and byte order.)

ChrisJumper · Post by **ChrisJumper** » Fri Oct 21, 2016 9:58 pm

JuNix wrote:I tried the proof of concept on my stable Gentoo system running gentoo-sources (Linux flatline 4.4.21-gentoo #1 SMP PREEMPT Tue Oct 11 14:23:47 BST 2016 x86_64 Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz GenuineIntel GNU/Linux), and my unpriveledged user managed to write to a read-only root owned file.

Start your favourite editor and search the Lines and insert the fix manualy. Just recompile your Kernel-Code.

Its easy.

For 4.4.21 the Positions are:
The define Fowllow COW at Line 2114 in include/linux/mm.h
The can_follow_write at line 60 in mm/gup.c
The second edit in that file for the retry sections is line 103 in the before edited gup.c
The third edit in that file is in line 363, in the before edited gup.c

Buffoon · Post by **Buffoon** » Fri Oct 21, 2016 10:33 pm

Interesting. Linus said he saw the problem 11 years ago, tried to fix it, but found it too difficult. Now the fix is just a few lines.

eccerr0r · Post by **eccerr0r** » Fri Oct 21, 2016 11:20 pm

miket wrote:You'd still have a problem. Nothing here tells you how they made the exploit-causing payload. There are two clues: 1. there are different versions for 64 and 32 bit and the 64-bit version is longer, and 2) they pad it with 0x90, which, as I recall, is the 8086 opcode for NOP. All this means that the exploit code is instruction-set specific.

They don't give a payload for ARM--if indeed a single payload would suffice. There are more flavors of ARM object code than there are for x86, after all! (Combinations of word length and byte order.)

1. It says MSFVenom is the source of the shellcode.
2. Likely MSFVenom knows how to output ARM code too, after all there is an ARM option in it. It even can dump Windows shellcode but of course the memory mapper of windows would be different...
3. Even if MSFVenom doesn't have it, you can write your own code no matter what the architecture as long as you have some compiler that will generate ELF. There's nothing tricky about the code, no stack smashing needed, if you can write user mode code you can write it yourself. I think it would be best if it fits within a page so no tricky mmaping to worry about, but not sure if even this is necessary - the page size of ARM is large enough that you can be sloppy.
4. Play-capable ARM-Android machines are all little endian else they would not have exploded in popularity.
5. And the target android device I have is much easier than all this: it's not armel at all, it's amd64.

Currently trying to install termux and see if clang will build a binary that will work... first problem is that termux installation has only i686...not sure how the 686 emulation page table mappings deal with CoW. I'd imagine it'd virtually share the same pool and the exploit would work...maybe...

[EDIT]
Ran into problem #1 : I can't seem to find any SUID root files that I can exploit... I guess I'll have to "edit" a startup script or something.

Olis · Post by **Olis** » Sat Oct 22, 2016 9:42 am

ChrisJumper wrote:
JuNix wrote:I tried the proof of concept on my stable Gentoo system running gentoo-sources (Linux flatline 4.4.21-gentoo #1 SMP PREEMPT Tue Oct 11 14:23:47 BST 2016 x86_64 Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz GenuineIntel GNU/Linux), and my unpriveledged user managed to write to a read-only root owned file.
Start your favourite editor and search the Lines and insert the fix manualy. Just recompile your Kernel-Code.

Its easy.

The PoC was working on my system (Kernel 4.4.21), too. Applied the patches, recompiled the kernel and restarted the system. PoC stopped working.

Thanks!

JuNix · Post by **JuNix** » Sat Oct 22, 2016 10:15 am

ChrisJumper wrote:
JuNix wrote:I tried the proof of concept on my stable Gentoo system running gentoo-sources (Linux flatline 4.4.21-gentoo #1 SMP PREEMPT Tue Oct 11 14:23:47 BST 2016 x86_64 Intel(R) Core(TM) i7-4790T CPU @ 2.70GHz GenuineIntel GNU/Linux), and my unpriveledged user managed to write to a read-only root owned file.
Start your favourite editor and search the Lines and insert the fix manualy. Just recompile your Kernel-Code.

Its easy.

For 4.4.21 the Positions are:
The define Fowllow COW at Line 2114 in include/linux/mm.h
The can_follow_write at line 60 in mm/gup.c
The second edit in that file for the retry sections is line 103 in the before edited gup.c
The third edit in that file is in line 363, in the before edited gup.c

Yeah, I think it's not hard to apply that, but doesn't this need doing by the kernel ebuild maintainers so that all Gentoo users can be sorted out when they next sync? There's no GLSA for it either.

eccerr0r · Post by **eccerr0r** » Sat Oct 22, 2016 1:18 pm

Yeah it's a fairly simple patch. There should be a patch "soon" I'd imagine.

https://bugs.gentoo.org/show_bug.cgi?id=597738

4.4.26 is coming!

ChrisJumper · Post by **ChrisJumper** » Sun Oct 23, 2016 10:27 am

eccerr0r wrote: I wonder if I can go root my android phone now without needing to do anything special... just need a cross compiler...

About that eccerr0r, i read a chat about that in the german heise.de Forum. Some think that this is not possible in Android Versions higher then 5.x*, and even the lower Versions, 4.3 using SELinux technique which make an exploit more difficult to apply.

The COW Article describe that this Exploit did not work on new Red Head Systems because it use SELinux, to handle the rights/access to /proc/self/mem.

But i am not sure what this /proc/self/mem Systems are. If this is a Kernel-Feature or some kind of Compiler feature, that you have to set a flag that your Application map its memory on some other way. Sounds like a sandbox-mechanism to me.

*Android 5 uses full file system encryption and restrict Access mechanisms. But when i ponder about this, the exploit is there if you can even create and read some files. That's normal userland stuff on a Phone too. And if you are root cause of the exploited Kernel Code, SELinux and even file encryption are no bigger hitches, if these mechanisms just check "root" and not "root + process ID + some kind of granted session cookies + a key to read from the file system". But since this is a Kernel-Bug the Kernelcode have all the access to the system.

But hey, its not wrong to update your Phone anyway.

eccerr0r · Post by **eccerr0r** » Sun Oct 23, 2016 2:02 pm

The target system is a Lollipop machine. I do see that it has user separation between apps, however, hoping that it affects root files. /proc/self/mem is writeable on this lollipop machine.

This shouldn't be an issue to begin with, my phone isn't exactly new and there are supposedly other rooting exploits out there. However this exploit I understand enough and not just downloading some closed source crap onto my phone that who knows what it's doing.

And yes I should have full rights to root on my own machines. The fact that they are deliberately trying to make it hard or impossible for the machine owner to have root is completely wrong. GRRR!

eccerr0r · Post by **eccerr0r** » Sun Oct 23, 2016 8:00 pm

Portage has gentoo-sources-4.4.26 now, everyone GOOOOOOO!!!! and stop hackers from commandeering your boxes and maybe slow down the botnet ssh attacks even though it technically doesn't need root access...

russK · Post by **russK** » Sun Oct 23, 2016 8:50 pm

JuNix wrote:There's no GLSA for it either.

Good point. Is this GLSA worthy?

eccerr0r · Post by **eccerr0r** » Sun Oct 23, 2016 8:55 pm

I'm sure there's a GLSA pending. I'm not a dev but it seems that first a fix needs to be in place and stabilized, then the GLSA announcement comes out. Since the bug has not been stabilized by all arches, no GLSA will be released. Should be real soon now.

There was another [glsa=201610-07]GLSA[/glsa] things apparently broke for... Announcement came out before all arches were stabilized. So there's some kinks...

tazinblack · Post by **tazinblack** » Mon Oct 24, 2016 6:41 am

Can anyone tell which starting from which gentoo-sources kernel version we are safe again?

Post by **fedeliallalinea** » Mon Oct 24, 2016 6:45 am

tazinblack wrote:Can anyone tell which starting from which gentoo-sources kernel version we are safe again?

https://bugs.gentoo.org/show_bug.cgi?id=597624#c2

tazinblack · Post by **tazinblack** » Mon Oct 24, 2016 9:14 am

fedeliallalinea wrote:
tazinblack wrote:Can anyone tell which starting from which gentoo-sources kernel version we are safe again?
https://bugs.gentoo.org/show_bug.cgi?id=597624#c2

Sorry for asking again.

affected:
<sys-kernel/gentoo-sources-4.8.3
<sys-kernel/gentoo-sources-4.7.9
<sys-kernel/gentoo-sources-4.4.26

Do I get this right? If you use one of the three versions above or higher you are not affected by dirty cow?

Post by **fedeliallalinea** » Mon Oct 24, 2016 9:54 am

tazinblack wrote:Do I get this right? If you use one of the three versions above or higher you are not affected by dirty cow?

I have not personally checked, but usually I trust the word of Gentoo developers

Bigun · Post by **Bigun** » Mon Oct 24, 2016 10:03 am

russK wrote:
JuNix wrote:There's no GLSA for it either.
Good point. Is this GLSA worthy?

I would think so. It's in the same vein as heartbleed or that recent TCP exploit.

Bigun · Post by **Bigun** » Mon Oct 24, 2016 10:44 am

All patched here, thanks for the quick work devs!