Rodrigo Freire & David Sirrine – Red Hat Technical Account Management Team

Dirty Cow (CVE-2016-5195) is the latest branded vulnerability, with a name, a logo, and a website, to impact Red Hat Enterprise Linux. This flaw is a widespread vulnerability and spans Red Hat Enterprise Linux versions 5, 6, and 7. Technical details about the vulnerability and how to address it can be found at: Kernel Local Privilege Escalation “Dirty COW” – CVE-2016-5195.

In order to be successful, an attacker must already have access to a server before they can exploit the vulnerability. Dirty Cow works by creating a race condition in the way the Linux kernel’s memory subsystem handles copy-on-write (COW) breakage of private read-only memory mappings. This race condition can allow an unprivileged local user to gain write access to read-only memory mappings and, in turn, increase their privileges on the system.

Copy-on-write is a technique that allows a system to efficiently duplicate or copy a resource which is subject to modification. If a resource is copied but not modified, there’s no need to create a new resource; the resource can be shared between the copy and the original. In case of a modification, a new resource is created.

While there is currently an updated kernel available that addresses this issue, in large data centers where affected systems can number in the hundreds, thousands, or even tens of thousands, it may not be possible to find a suitable maintenance window to update all the affected systems as this requires downtime to reboot the system. RHEL7.2 systems or above can be live-patched to fix this issue using kpatch. In order to take advantage of this Red Hat benefit, file a support case, inform about the kernel version, and request a suitable kpatch. For more details about what a kpatch is see: Is live kernel patching (kpatch) supported in RHEL 7?

RHEL 5 and 6, while affected, do not support kpatch. Fortunately, there is a stopgap solution for this vulnerability using SystemTap. The SystemTap script will apply the patch while the system is running, without the need of a reboot. This is done by intercepting the vulnerable system call, which allows the system to continue working as expected without being compromised.

A word of caution: this SystemTap solution can potentially impair a virus scanner running in the system. Please check with your antivirus vendor.

The SystemTap script is relatively small and efficient, broken into 4 distinct sections as follows:

probe kernel.function("mem_write").call ? {
        $count = 0
}

probe syscall.ptrace {  // includes compat ptrace as well
        $request = 0xfff
}

probe begin {
        printk(0, "CVE-2016-5195 mitigation loaded")
}


probe end {
        printk(0, "CVE-2016-5195 mitigation unloaded")
}

First, the script places a probe at the beginning of the kernel function “mem_write” when called and not loaded inline:

probe kernel.function("mem_write").call ? {
        $count = 0
}

Next, the script places a probe at the ptrace syscalls that disables them (this bit can impair antivirus software and potentially other kinds of software such as debuggers):

probe syscall.ptrace {  // includes compat ptrace as well
        $request = 0xfff
}

Finally, the “probe begin” and “probe end” code blocks tell systemtap to add the supplied text to the kernel log buffer via the printk function. This creates an audit trail by registering in the system logs exactly when the mitigation is loaded and unloaded.

This solution works in all affected RHEL versions: 5, 6, and 7.

Red Hat always seeks to provide both mitigations to disable attacks as well as the actual patches to treat the flaw. To learn more about SystemTap, and how it can be used in your management of your Red Hat systems, please refer to Using SystemTap or one of our videos about it within our Customer Portal.

Again, for more information on how to use the SystemTap solution or to see links to the available patches, please visit the “Resolve” tab in the related Red Hat Vulnerability Response article.