What is Dirty COW?
It’s the name given to a newly discovered vulnerability in virtually all versions of the Linux operating system. More accurately it should be referred to as CVE-2016-5195 – but where is the fun in that?
But why Dirty COW?
According to the researchers who found the flaw, and created a website to share information about it:
“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. An unprivileged local user could use this flaw to gain write access to otherwise read-only memory mappings and thus increase their privileges on the system.”
Essentially it means that – if the vulnerability is left unpatched – if a local user can read a file, they can also write to it. Ouch!
So this is a privilege escalation vulnerability, rather than a potentially more dangerous code execution vulnerability?
Right. But don’t let that thought lure you into resting on your laurels, as researchers claim they have found an in-the-wild exploit using the vulnerability.
Okay. Is this a new vulnerability?
Umm.. unfortunately not. Although it has only recently been uncovered, it appears that the flaw has been present in the Linux kernel for going on nine years.
Sheesh.. isn’t the whole point of open source software that it’s available for anyone to review, find bugs, etc…? How come this wasn’t spotted and fixed earlier?
Just earlier this week, research was published claiming that Linux bugs have a typical lifetime of approximately five years.
I run Red Hat / Debian / Ubuntu. Where can I find out more about what I should be doing.
Be sure to check out the official Dirty COW website (yes, they have a website as well as a Twitter account, and the now obligatory vulnerability logo) at http://dirtycow.ninja/
Found this article interesting? Follow Graham Cluley on Twitter or Mastodon to read more of the exclusive content we post.
3 comments on “Dirty COW Linux vulnerability – what you need to know”
‘for going on nine years.’
Actually it’s eleven years. Also, Linus attempted to fix it (badly as he put it) but there was another problem which made him roll it back (s390 architecture). He explains it all: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
The fix is actually quite simple but was likely simply forgotten (I know I’ve done this many times before) so once the other problem was resolved this wasn’t.
Edit: I meant to say: thanks for the ‘offal’ pun.
Also: ‘So this is a privilege escalation vulnerability, rather than a potentially more dangerous code execution vulnerability?’
But often the latter (e.g. spawning a root shell) leads to former and depending on the privileges gained it is arguably just as bad.
Code execution: if you can write to a file owned by root, you could replace, say, the /bin/ping binary with another malicious binary, which you could then run as root. As I understand it.
The point was very often code execution can lead to privilege escalation i.e. they might as well be the same thing in the end. Also, I would say that privilege escalation (to root) is equally as bad if not worse because if you root the system you can also run that code (not to mention doing a load of other things).