Dirty COW vulnerability - is your Linux patched?

A bit late to the game I realized I should be patching my linux systems, especially if I continue to use Docker for various "appliances" (simply using Docker to invoke tools via Docker images without having to worry about installation/compilation/dependencies ...).

Apart from some currently powered down kit I need to remember to fix later (a couple of NUCs running Ubuntu 16.04 LTS, some Raspberry Pis) I've a desktop and a laptop both running Fedora 24.

The goal of this post is to gather the essential information so that you can quickly check if you have the vulnerability and how to patch it.

What is the Dirty COW vulnerability

It's a serious linux kernel flaw, ably described in this excellent blog post "Dirty COW - (CVE-2016-5195) - Docker Container Escape".  

Is my system vulnerable?

This blog post details how to fix the vulnerability on several Operating Systems, this may be all you need but I propose we check before/after if the vulnerability is present.

This page lists several POCs (Proof of Concept) of the exploit.

Trying the dirtyc0w.c POC, raw C code is here.

Create a temporary directory, e.g. /tmp/dirtycow

$ mkdir /tmp/dirtycow
$ cd /tmp/dirtycow

Copy/paste that code into a file named dirtyc0w.c
Then follow the instructions" in that file, reproduced here:

Change to the root use and create a test file foo, then exit this root shell.

$ sudo -s
# echo this is not a test > foo
# chmod 0404 foo
# exit

Now as a normal user, list the file
Note that this file is readable but no one can write to the file, normally ...

$ ls -lah foo
-r-----r-- 1 root root 19 Oct 20 15:23 foo
$ cat foo
this is not a test

Now we will build and run the dirtyc0w proof of concept as follows:

$ gcc -pthread dirtyc0w.c -o dirtyc0w
$ ./dirtyc0w foo m00000000000000000
mmap 56123000
madvise 0
procselfmem 1800000000
$ cat foo
m00000000000000000

Note that running our executable as a normal user allowed us to exploit this bug and overwrite a file for which we don't have access rights.   We're vulnerable ...


Fixing the vulnerability

Well hopefully just performing an OS update, e.g. as described in the same blog post referred to earlier wll fix the problem and this post will not go further except to cover my case, Fedora 24.

In my case I was running an "old" Linux kernel 4.7.6 where this bug report, Bug 1384344, at comment #43 informs us that the fix is available in kernel 4.8.4.

Of course all that's needed on Fedora 24 now is to perform a standard OS update using

sudo dnf update

But dont' forget to reboot !!

Then retry the above vulnerability check - no need to recompile, but you need to regenerate an initial file foo with known contents before running the check.

Back to work ...

OK, time to get back to work, it's one of those Saturdays of following the rabbit down the hole ...