If you’ve heard of a Black Cow, you may think that Dirty C0w is a variation on that drink.

In reality, Dirty C0w is a privilege escalation vulnerability that is present in the Linux kernel.

While the Dirty C0w vulnerability was only recently disclosed to the public, at 9 years old it is indeed quite an old vulnerability.

You, dear readers, may be wondering about the origination of the name ‘Dirty C0w’; it is simply a play on words.

The reference is to Copy-On-Write, also known as ‘COW’. It is a funny name with not-so-funny consequences.

Should you be concerned about this vulnerability? Yes.

Is the presence of this vulnerability incentive enough to disrupt the normal course of business and immediately patch the Linux Kernel? Probably not.

While Dirty C0w is a serious vulnerability it is not exploitable without access to the command line of a server.

If for instance, you have database servers that are locked down tightly with access restricted to only a few trusted individuals, it is probably safe to plan for this patch to occur during the normal patch cycle.

What if however, the situation is such that many people have access to the server?

Then you must consider the type of access these folks have.

If the accounts already allow for privileged access, then there is little danger in the current accounts making use of the Dirty C0w exploit, as they already have privileged accounts.

The situation is different though if those Linux accounts have restrictions.

Here at Pythian we care for many different Linux database servers, for many different customers. Some of these customers allow us root access, some do not.

Pythian recommends that all clients plan to patch for the Dirty C0w as necessary. This patching is more urgent however for our clients where we do not have privileged (root) access.

Why is that?

• Patching protects our client and gives them peace of mind. Pythian is very serious about providing a secure environment for their employees to work in customer environments. Removing an easily exploited vulnerability increases that security.
• This is also a protection for Pythian. Should some security related event occur on one of our customer’s servers, we will know it cannot be traced back to someone exploiting the Dirty C0w vulnerability.

If you have read some of the articles that have recently appeared about this exploit, you may have read that Linux versions 5 and 6 are not affected by the Dirty C0w vulnerability.

That is incorrect, as these versions certainly are affected. As per the RedHat CVE-2016-5195 both versions 5 and 6 are affected. I have successfully tested this exploit on Linux 6.6 as well.

And now for some technical content

So, what exactly happens with Dirty C0w? In short, it allows modification of files that would not normally be allowed.

This is aptly demonstrated by this sample code for dirtyc0w.c.

The flow of this test is as follows:

• create a root owned file with known contents –
  • access to non-privileged users is read only
• run dirtyc0w as an unprivileged user to alter the file contents
• check the file contents

Please note this exploit fails on files that cannot be read by the user attempting to run the exploit.

Within the C source, there are two loops that count to 100 million to invoke the race condition required to exploit this vulnerability.

With testing, I found that on the Linux 7.2 server used for these tests, loops of 5 million iterations were sufficient to ensure this test always succeeds. doing so reduced the testing time from 73 seconds to 3.6 seconds per iteration.

The following scripts were used to execute dirtyc0w 100 times and record the results.

create-root-file.sh

#!/bin/bash
 
cat < ~ec2-user/dirtyc0w/foo
this is not a test
EOF
 
chmod 444 ~ec2-user/dirtyc0w/foo

run-multi.sh

#!/bin/bash
 
i=0
 
while [[ $i -le 100 ]]
do
 
   echo "##### Attempt $i #####"
   echo "reset foo"
   sudo su - -c ~ec2-user/dirtyc0w/create-root-file.sh
   echo foo contents
   cat foo
   echo run dirtyc0w
   time ./dirtyc0w foo m00000000000000000
   echo foo contents
   cat foo
 
   (( i++ ))
done | tee run-multi.log
 
echo
echo Results:
 
grep -B1 '##### Attempt' run-multi.log | grep -vE 'Attempt|^--' | sort | uniq -c

Here are the test results: 100 tests, all successful.

[ec2-user@ip-172-31-1-160 dirtyc0w]$ grep -B1 '##### Attempt' run-multi.log | grep -vE 'Attempt|^--' | sort | uniq -c
100 m00000000000000000

Conclusion

With a little imagination you can likely come up with many methods where this exploit could prove dangerous. For instance, one of the first that came to mind was modifying /etc/sudoers; this should send shivers down the spine of any System Administrator.

Should you patch for the Dirty C0w vulnerability? Definitely!

RedHat has provided a script that can be used to determine if the kernel is vulnerable to Dirty C0w. This script can be obtained with the following command:

wget https://access.redhat.com/sites/default/files/rh-cve-2016-5195_2.sh

Here is an example usage:

[root@oravm01 tmp]# wget https://access.redhat.com/sites/default/files/rh-cve-2016-5195_2.sh
--2016-10-26 11:07:25--  https://access.redhat.com/sites/default/files/rh-cve-2016-5195_2.sh
Resolving access.redhat.com... 23.200.209.128
Connecting to access.redhat.com|23.200.209.128|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 16478 (16K) [application/x-sh]
Saving to: `rh-cve-2016-5195_2.sh.1'
 
100%[================================================================================================================================================>] 16,478      --.-K/s   in 0.01s
 
 
2016-10-26 11:07:25 (1.32 MB/s) - `rh-cve-2016-5195_2.sh.1' saved [16478/16478]
 
[root@oravm01 tmp]# bash ./rh-cve-2016-5195_2.sh
Your kernel is 2.6.18-194.el5 which IS vulnerable.
Red Hat recommends that you update your kernel. Alternatively, you can apply partial
mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .

Though the script is from RedHat, it does work on RedHat derived versions of Linux such as Oracle Enterprise Linux, CentOS, etc.

The urgency of patching any system will need to be determined on a case by case basis.

The patching itself is not difficult. With RedHat and its derivatives the kernel may be updated with yum -y update kernel.

Patching the kernel will require a reboot of the server.