I heard about Dirty COW but couldn't find any decent writeup on the scope of the bug. It looks like the exploit can overwrite any non-writable file, which makes me guess that local root is possible via substitution of SUID programs. Is that right? What else do we know about Dirty COW? Is it possible to exploit it remotely? Does it affect Android?


7 Answers 7


It can't be exploited remotely without another vulnerability. You need to be able to execute commands on the system already.

A classic example would be a web shell. Say the server is running a web application which has a vulnerability allowing you to upload a web shell or otherwise execute system commands. These commands will typically be executed as a low-privileged user, sometimes called www-data or similar.

With this exploit you could overwrite the file /etc/passwd to give www-data the UID 0. Now www-data has root privileges.

However, I tried a few things and modifying /etc/passwd didn't work on my system. You can set the UID of a user to 0, but then you'd have to re-login, which isn't really an option if you only have a web shell. The best weaponized exploit I've seen so far overwrites /usr/bin/passwd, the binary which is used to change a user's password and has the SUID bit set, with shellcode that executes /bin/bash. Some limitations of the exploit seem to be: You can only overwrite existing bytes, not add anything to a file. I was also not able write more than exactly 4KB to a file.

As for affecting Android, I searched the Android 4.4 git repo for the function in question (follow_page_pte) and got no hits, so I want to say "no", but don't quote me on that.

Edit: Android is affected - see this proof of concept.

  • 4
    The android git repo wouldn't necessarily need to call follow_page_pte to be vulnerable. It's possible for Android apps to include native C code, so could in principle include C code similar to the exploit. In practice, Android's sandboxing model may defuse some attacks.
    – James_pic
    Commented Oct 21, 2016 at 15:55
  • 3
    – s3v3n
    Commented Oct 22, 2016 at 17:55
  • Note: the Shellshock Vulnerability also required "can execute commands on the system", but because of the way some webserver software worked, it still allowed remote code execution. I wouldn't be surprised if we had a similar situation here.
    – Nzall
    Commented Oct 22, 2016 at 22:11
  • Rewriting /etc/passwd then causing the system to reboot, (filling tmp?) or somehow causing a new www-data account to log in? (fill your own local tmp up? Do another http request? Do many http requests?)
    – Yakk
    Commented Oct 24, 2016 at 14:27
  • @Nzall : The shellshock was a entirely different exploit. It was more of a injection exploit, so if a enviroment variable contained a command, you could "escape out" of enviroment and gain access to a local shell. So shellshock PLUS dirtycow = EXTREMELY TOXIC. So basically, shellshock is a remote exploit giving local user access, and dirtycow is a exploit giving root access to someone with local user access. Needless to say, the combination is very dangerous. Commented Oct 28, 2016 at 4:54

The dirty cow vulnerability, is a a privilege escalation vulnerability in Linux kernel versions 2.6.22 and higher; it has existed since 2007 and was fixed on Oct 18, 2016.

What is the possible impact of dirtyc0w bug?

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.

This flaw allows an attacker with a local system account to modify on-disk binaries, bypassing the standard permission mechanisms that would prevent modification without an appropriate permission set.

Is it possible to exploit it remotely?

it is not directly exploitable remotely; you first need another flaw to give you remote access to the system ,as motioned @IMSoP in his comment,

it is rated as an important bug :

Important impact

This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.

Does it affect Android?

Yes, because Android uses the Linux kernel.

Am I affected?

If you have any device running a Linux kernel higher than 2.6.22, there’s a good chance that you are vulnerable. The same goes for all versions of Android whether they come from Samsung, Google, Cyanogen, MIUI, or other vendors because they have not yet issued security updates.

In order to exploit this vulnerability, the attacker needs to run code in the affected device, which in Android’s case can be done via the Android Debug Bridge (ADB) over USB or by installing an app that makes use of the exploit.


A security searcher describes on this blog how to exploit the flaw remotely

The exploits can be used against Web hosting providers that provide shell access, so that one customer can attack other customers or even service administrators. Privilege-escalation exploits can also be combined with attacks that target other vulnerabilities. A SQL injection weakness in a website, for instance, often allows attackers to run malicious code only as an untrusted user. Combined with an escalation exploit, however, such attacks can often achieve highly coveted root status.

Useful information can be found here:

  1. How to determine if your system is vulnerable?
  2. What is the list of affected Linux distros?
  3. How do I fix it?
  • 17
    I think it's a terminology confusion: from your description, it is not directly exploitable remotely; you first need another flaw to give you remote access to the system. Once you have the ability to run arbitrary commands, those commands are effectively "local" to the system. For instance, commands run over an established SSH connection aren't usually classified as "remote" in this sense, because there's little meaningful distinction between them and commands typed on a terminal which is physically attached to the system.
    – IMSoP
    Commented Oct 21, 2016 at 13:42
  • 7
    -1 the bug is NOT remotely exploitable.
    – psmears
    Commented Oct 21, 2016 at 16:28
  • 21
    Everything is "remotely exploitable" if you assume a secondary flaw that gives you local access... By remotely exploitable we generally mean: the flaw can be triggered without such local access to a web shell or similar.
    – Bakuriu
    Commented Oct 21, 2016 at 16:45
  • 4
    I think you are misreading the definition. Vulnerabilities are labeled "important" when they meet at least one of the listed criteria -- in this case, it allows local users to gain privileges or may allow authenticated remote users to do so. If the exploit were known to b exploitable directly by unauthenticated remote users, it would be marked "critical" instead. (N.B. I am not speaking officially for RH here)
    – mattdm
    Commented Oct 21, 2016 at 17:24
  • 3
    Your answer about android exploitation is poorly researched. Android DOES use the Linux kernel, however, that doesn't mean the vulnerability can be exploited in Android. Also, the answer about remote exploitation is misleading, at best. Commented Oct 21, 2016 at 18:25

CVE-2016-5195 is a so-called privilege escalation exploit. It allows you to elevate the privilege level from a normal Linux user to root. But privilege escalation exploits are usually local exploits (which means they run locally on a box), which means you already need to be logged on to the operating system.

The public exploit I was checking allows to write files owned by root which are read-only or not accessible at all to non-root users. This allows you to overwrite administrative files. You can leverage this to become root. E.g. you can add a line


to /etc/passwd. This would add a root user without password to the box.


At least it does affect Android 5.0.1 (Kernel Version 3.10.54+). I just tried out this code on a device using Termux and editing a file owned by root works flawlessly. I like that, because there is no root available for that device.

On the other hand, it surprises me, because Android uses SELinux and I thought SELinux would prevent writing to /proc/self/mem.

Actually, I just tried out writing to a file owned by a user called sdcard, who owns all files on the SD card. Termux itself is (normally) not allowed to write to the SD card. When I try out dirtyc0w on such a file, the device just hangs and reboots automatically after a few seconds. Even adb logcat doesn't output anything during this hang. Not sure what's going on there.


How scary is it?

In principle, a privilege escalation is quite scary since it more or less renders all access control meaningless. In practice, it hopefully matters little. You first have to have limited user access.

For servers, it will mean that not-so-well maintained server systems that are somewhat exploitable now will be trivially rootable. It's not like this is the first privilege escalation exploit in history, though.
For well-maintained systems, the impact should close to zero (they should not have been exploited so far, and should be updated by now).

For all Android phones before 7.0, it unluckily means that there is an exploit which might allow a malicious app to take over the phone. That is an extremely scary thought, but it doesn't seem to have happened so far, or there would be panic, chaos, and murder all over the planet. Automatic updates will do away with this issue quickly, and in the mean time do not install new apps (the apps already present on your phone for many months obviously didn't hijack your phone, so they're probably harmless)... problem solved.
There's now yet another way of jailbreaking your phone, too (until the next system update, at least).

It also obviously means that someone with physical access to your computer and a user account can root your system... but they could as well just grab your computer and carry it away, or steal the harddisk, or use Firewire/Thunderbolt which are basically direct memory access over cable, boot from a CDROM, or... 200 other things, so I don't think this is a big issue overall. It is just yet-another-thing someone can do.

More importantly

Since this is the second long-standing, high-profile incident (after CVE-2008-0166) where an arguably serious security issue was created by a maintainer on behalf of a "what do I care?" issue, I hope that the biggest impact this will have will reopen a discussion on engineering process.

The biggest issue about this vulnerability is, in my opinion, that it was identified and fixed in 2005 (when it was merely a theoretical problem with a low likelihood of occurring), but then reverted because it caused a problem on some IBM mainframe series from the early 1990s that few people have ever heard of. Which, frankly, 99% of all Linux users couldn't care about less, and which could have been done by a system-dependent patch/fix for just s/390. But that didn't happen, and the problem faded into oblivion until 11 years later.

This is very similar to the introduction of 2008-0166 where someone edited out code (which worked correctly) without understanding the implications, solely because Valgrind showed a warning.

Maybe, this will help creating more awareness of the importance of maintainers understanding what the exact implications of a code change are for the vast majority of users, and an overall more critical assessment (with peer review?) on code changes may evolve. Hopefully, that is.

  • 5
    "Automatic updates will do away with this issue quickly" - somehow I don't believe you. What percentage of phones actually do get automatic updates?
    – d33tah
    Commented Oct 22, 2016 at 11:49
  • @d33tah: I obviously don't know (how could I). But seeing how phones are almost more "owned by manufacturer" than owned by their owner, close to 100%? My phone (which is an iPhone, not Android, but anyway) seems to auto-update itself about at least once every two weeks (feels like almost every day), and the option to turn this off, if there is one, is so well-hidden that I don't even know where to find it. Sure, I can delay the update, but it will nag me with "install now" every time I press the wakeup button. While annoying, all in all, I deem this frequent auto-update a good feature.
    – Damon
    Commented Oct 23, 2016 at 11:45
  • 2
    @Damon Android 5.0 was released two years ago, but 50% or so of Android phones still run 4.4 or older. See developer.android.com/about/dashboards.
    – suriv
    Commented Oct 23, 2016 at 13:27
  • @Damon Alas, the Android update situation is far, far different than the iOS update situation. With the exception of a (relative) few major manufacturers that have now begun servicing a few phone models available on a few major carriers in a timely manner, owners of Android phones made by large OEMs can still generally expect either (a) updates that actually get to their phones weeks or months after Google first released them to the OEMs, or (b) no updates at all. Commented Oct 24, 2016 at 19:12

The Guardian seems to say its a YES, but it looks like it depends on the variant of Android in question:

That also applies to Android: the mobile operating system is affected. While top-end Android devices, such as the Galaxy S7 and Pixel, receive regular security updates, the vast majority of Android devices sold receive few, if any, post-sale updates.

Google declined to comment, but confirmed that Android is one of the Linux distributions affected. The company has posted a Partner Security Advisory to alert Android partners, one of the steps to those partners then issuing a patch.


The bug allows an attacker than can execute arbitrary code to write to memory that is "read only". Linux caches often used files in read only memory. As you guessed, this allows you to do things like change the contents of a setuid root file to execute arbitary code, like a shell, as root.

The bug in and of itself isn't remotely exploitable since it requires the attacker to execute a specific executable created by the attacker. Typically when we use the words "remotely exploitable", it doesn't require ability to execute arbitrary code.

However, there ARE situations where an attacker can already execute arbitrary code by design that aren't as obvious as ssh access. This may be the reason for some of the confusion, as it may not always be obvious that an attacker has code execution privileges. Potentially, shared automated build environments may be vulnerable to this type of exploit, as they often allow the developer to execute arbitrary code. An attacker in this scenario could potentially gain root privileges.

I don't feel I'm qualified to answer if this bug is exploitable in Android. If it is exploitable on Android the scope would most likely be limited to the owner of the phone being able to "root" the device, rather than a remote attacker gaining any control over the phone.

  • it just would mean that application sandbox doesn't work and any application can pwn the device regardless of user approval — like in MS-DOS Commented Oct 23, 2016 at 5:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .