Dirty COW Vulnerability

  • Post author:
  • Post category:General
You are currently viewing Dirty COW Vulnerability

 

More internet challenges are sprouting up as technology is sharpening its focus. One of the recently reported bugs is the privilege alteration or dirty COW vulnerability in the Linux kernel. The vulnerability emanates from the Resource Optimisation Strategy and Copy-on-write (COW) of the Kernel’s memory handler; hence it is termed as dirty COW [CVE-2016-5195.

The fundamental idea behind COW is, if multiple processes or callers requested for a particular resource a link to the resource will be allocated instead of creating a private copy of the resource for each process. This rule can be applied safely until a process tries to modify the resource. Before modifying the resource, a true private copy will be created to prevent the changes visible to the other callers. No private copy is required, if none of the callers make any modification.

As per the red hat security reports(https://access.redhat.com/security/cve/CVE-2016-5195), the vulnerability can be described as:
“A race condition was found in the way the Linux kernel’s memory subsystem handled the 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.”

Within a short amount of time, it is not possible to get a clear picture of the affected Linux kernels. Due to the complexity of this attack, it is hard to detect the malicious activity from its normal usage. Of course, these may raise hundreds of doubts about the future of Linux based servers! Linux will come with an answer soon. As of now, we have the option to mitigate the issue by adopting the following steps

1) On the host, save the following in a file with the “.stp” extension:

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”)}

2) Install the “systemtap” package and any required dependencies. Refer
to the “2. Using SystemTap” chapter in the Red Hat Enterprise Linux
“SystemTap Beginners Guide” document, available from docs.redhat.com,
for information on installing the required -debuginfo packages.

3) Run the “stap -g [filename-from-step-1].stp” command as root.

Note : The script needs to re-run every time the server is rebooted until your kernel is patched or a safe kernel is released.

This mitigation step will disable the system ptrace functionality that debuggers or programmers use to trace while running their program.

 

Leave a Reply