I am sure many of you remember the XKCD Heartbleed Explanation. In the same spirit, I would like to request an explanation for how the latest branded vulnerability, Dirty COW, works.

Is it possible to explain it to someone like me, who have no idea how the Linux kernel works or what a "copy-on-write" is? Please note that I am not looking for an explanation of what it does, but of how and why it works.


I'm not a linux kernel expert, but I am familiar with the concepts involved and I read Linus' comment and the diff. I'll give it a go - perhaps people can correct me if I get it wrong and we'll hash things out together.

Copy On Write is an internal memory concept where, primarily for performance reasons, operations that make a copy of a section of memory don't actually get their own copy unless and until they make a change to that memory - at which point, you quickly make their copy, make the change to that and hand it back to them. The advantage is that you don't have to do the work of making the copy unless and until they actually change it - faster, less memory usage, better caching.

The bug here is in the code that does that copying. It appears that there is a race condition in that copy (or actually in the bookkeeping around that copy). A race condition happens when two different processes or threads are accessing the same resource and step on each other. In this case, what happens is that the memory is flagged to be writeable before it is actually copied - if two threads are working very closely to each other, the second can take advantage of the writeable flag and actually write to the original memory, not the copy.

The exploit is that this lets a process elevate itself by getting write access to the kernel's own understanding of it. The kernel knows what user each process is running at - by taking a copy of that memory that kernel is using to store that info using Copy On Write, then using this Dirty COW bug, they can actually write the user info into the kernel's own copy. So they write that the process is being run as root.. and then they can do anything.

The demo program uses that to write to a file only writeable by root, but it could have done literally anything. The fix was to separate out a new flag saying they are doing a CopyOnWrite, instead of using the Write flag for both.

| improve this answer | |
  • 2
    On spot (+1). The only thing I'd add is that (if you want to be pedantic) you are not really writing to a kernelspace page. The write happens when the kernel already believes that the process is done with the page, but before the page is marked as kernelspace (so the CPU/MMU would disallow the write). – grochmal Oct 22 '16 at 14:53

You and 3 other people are studying for a test, using the same notes.

You say "I gotta go, I need to make a copy of these notes for myself that I can mark up... let me go make a copy!"

You take the notes to the photocopier, copy them, alter the original, and then take the modified original back to the rest of the group. That modified version is bad; you've altered some answers to be wrong.

The rest of the group is left studying off of a bad version of the notes, while you take the good version home.

You pass the test.

They fail.

The only nuance between this example and Dirty COW is that in Dirty COW you aren't supposed to be handed the original; the kernel makes the copy for you. But there's a race condition that mistakenly gives you access to the original when you ask for a copy. "Race condition" means "you can sneak in access to something you shouldn't have access to."

| improve this answer | |
  • 2
    I have to say gowenfawr, your explanation is my far the best "complete idiots guide..." definition I've seen. That is a compliment by the way...you found a way to make it understandable to everyone......+1 and kudos – Amazingred Oct 24 '16 at 23:27
  • This is much closer to the equivalent xkcd then mine – crovers Oct 25 '16 at 19:29
  • Oh you made it crystal clear. Thank you. BTW, How easy would it be to explore this vulnerability? – randon Oct 27 '16 at 9:56
  • 1
    @randon there's exploit code available; it doesn't get any easier to explore than that... grab a copy of the code and spin up a vulnerable OS VM to play with. – gowenfawr Oct 27 '16 at 12:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.