What is the possible impact of dirtyc0w a.k.a. "Dirty COW" bug?

Question

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?

Answer 1

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.

Answer 2

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.

Update

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?

Answer 3

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

hack::0:0:,,,:/home/kai:/bin/bash

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

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.