wesupport

Need help?

Our experts have had an average response time of 13.14 minutes in February 2024 to fix urgent issues.

We will keep your servers stable, secure, and fast at all times for one fixed price.

How to fix Dirty Cow vulnerability in CentOS, RedHat, Ubuntu, Debian, CloudLinux and OpenSuse Linux servers

by | Oct 22, 2016

Dirty COW vulnerability was first discovered a decade ago and has been present in Linux kernel versions from 2.6.22, which was released in 2007.

But the vulnerability gained attention only recently when hackers started exploiting it. This has led to the release of this bug as CVE-2016-5195 on October 19th, 2016.

What is Dirty Cow vulnerability (CVE-2016-5195)?

CVE-2016-5195 aka “Dirty COW vulnerability” involves a privilege escalation exploit which affects the way memory operations are handled.

Since the feature that is affected by this bug is the copy-on-write (COW) mechanism in Linux kernel for managing ‘dirty’ memory pages, this vulnerability is termed ‘Dirty COW’.

Misusing this flaw in kernel, an unprivileged local user can escalate his privileges in the system and thus gain write access on read-only memory updates.

Using this privilege escalation, local users can write to any file that they can read. Any malicious application or user can thus tamper with critical read-only root-owned files.

Are your servers vulnerable to attacks?

CLICK HERE TO PROTECT YOUR SERVERS NOW!

Is Dirty Cow vulnerability (CVE-2016-5195) critical?

Dirty COW vulnerability affects the Linux kernel. Most open-source operating systems such as RedHat, Ubuntu, Fedora, Debian, etc. are based over Linux kernel.

As a result, this vulnerability is a ‘High’ priority one as it can affect a huge percentage of servers running over Linux and Android kernels.

CVE-2016-5195 exploit can be misused by malicious users who are provided with shell access in Linux servers. They can gain root access and attack other users.

When combined with other attacks such as SQL injection, this privilege escalation attack can even mess up the entire data in these servers, which makes it a critical one.

Are you servers affected by Dirty Cow exploit?

If your server or VM or container is hosted with any of these OS versions, then they are vulnerable:

  1. Red Hat Enterprise Linux 7.x, 6.x and 5.x
  2. CentOS Linux 7.x, 6.x and 5.x
  3. Debian Linux wheezy, jessie, stretch and sid
  4. Ubuntu Linux precise (LTS 12.04), trusty, xenial (LTS 16.04), yakkety and vivid/ubuntu-core
  5. SUSE Linux Enterprise 11 and 12

First step to do is to check your OS flavor and to know your Linux kernel version, using the ‘uname’ command:

Know your OS

Know your OS

Here, the OS is Ubuntu and kernel version is 3.13.0-24-generic.

Identify your Linux kernel version

Identify your Linux kernel version

If the kernel version displayed in your server is earlier than these patched versions, your server is vulnerable:

  • 4.8.0-26.28 for Ubuntu 16.10
  • 4.4.0-45.66 for Ubuntu 16.04 LTS
  • 3.13.0-100.147 for Ubuntu 14.04 LTS
  • 3.2.0-113.155 for Ubuntu 12.04 LTS
  • 3.16.36-1+deb8u2 for Debian 8
  • 3.2.82-1 for Debian 7
  • 4.7.8-1 for Debian unstable

How to protect your servers from Dirty Cow bug

Dirty COW privilege escalation vulnerability in the Linux kernel has been acknowledged and patch has been already released for the kernel.

Some major OS vendors have released the security patches for their OS versions. So, the immediate fix is to update the software in your servers.

If your server is configured for automatic software updates, the server would have already got the new patch installed.

But for the installed updates to come into effect, you will have to reboot the server.

Most live servers disable automatic updates due to the fear of mess-ups. In such cases, you have to manually update the OS to the secure version.

CLICK HERE TO PROTECT YOUR SERVERS NOW!

Here, we’ll discuss how to update the different OS flavors in your servers.

1. How to mitigate Dirty Cow vulnerability in CentOS and RedHat servers

RedHat has released the updated OS versions with the security patch for Dirty Cow vulnerability. To update the OS with this security patch, use ‘yum update’.

Once the update is complete, you may have to reboot the server for the patched OS to load. For servers in which OS update cannot be done, there is a temporary mitigation:

1) Create a file “update.stp” and add these lines:

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 its required dependencies.

3) Execute the command “stap -g update.stp” as root. As system reboot can tamper with this patch, these steps would have to be repeated in case of reboots.

2. How to fix Dirty Cow vulnerability in Ubuntu and Debian servers

Update the OS with the latest security patch available from the OS repository. This can be done using these commands:

sudo apt-get update && sudo apt-get dist-upgrade

Once the update is complete, reboot the server for the updates to come into effect.

3. How to fix Dirty Cow vulnerability in OpenSUSE servers

OpenSUSE has released the vulnerability patches for their OS versions. To apply the patch, run the command:

zypper patch

Once the update is complete, reboot the server for the updates to come into effect.

4. How to fix Dirty Cow vulnerability in CloudLinux servers

To update the security patch for CloudLinux 7, the steps are:

yum clean all; yum install kernel-3.10.0-427.10.1.lve1.4.22.el7 kmod-lve-1.4-22.el7 --enablerepo=cloudlinux-updates-testing

For CloudLinux 6, follow these steps:

yum clean all; yum install kernel-2.6.32-673.26.1.lve1.4.18.el6 kmod-lve-1.4-18.el6 --enablerepo=cloudlinux-updates-testing

Once the kernel updates are installed, reboot the server for the new kernel to come into effect.

SECURE YOUR SERVERS FROM ALL ATTACKS!

In short..

Today we saw the implications of running a server with the Dirty COW vulnerability and how to secure your servers.

‘Dirty COW’ is a zero-day vulnerability and its hard to detect the attack. So securing your servers immediately with the patch is crucial to avoid a hack.

But updating the software packages and applying the patches or mitigation steps should be done by experts and with utmost caution.

At Bobcares, our 24/7 security expert team keeps track of the vulnerabilities and apply patches to our customers’ servers within no time.

If you’d like to know how to secure your servers with the best security practices and to ensure 24/7 pro-active administration, feel free to contact us.

 

Don't let your servers go for a toss!

Attacks can occur any time! Be safe now, than being sorry later!

Our engineers will assist you to setup, monitor and manage your server infrastructure 24/7.

GET YOUR SERVERS SECURED NOW!

var google_conversion_label = "owonCMyG5nEQ0aD71QM";


Bobcares provides Outsourced Hosting Support and Outsourced Server Management for online businesses. Our services include Hosting Support Services, server support, help desk support, live chat support and phone support.

22 Comments

  1. Marcelo

    Beware, systemtap doesn’t protect from all vectors of the attack!
    Read KernelCare blog for more details. Also those guys allow to live patch existing distros w/o need for reboot.

    Reply
    • Reeshma

      Marcelo,

      Yes, Systemtap method is only a mitigation strategy against In The Wild (ITW) exploit, until RedHat releases their updated secure versions. Its not a permanent solution. Manually recompiling and securing the kernel is always the most recommended advice always.

      Reply
  2. Roham Sakhravi

    semantic error: while resolving probe point: identifier ‘syscall’ at roham.stp:5:7
    source: probe syscall.ptrace { // includes compat ptrace as well
    ^

    semantic error: no match

    ———————————————————-
    This won’t work for RedHat 5 & 6.

    Reply
    • Reeshma

      Roham,

      As mentioned in our post, you would have to install the required dependencies for the ‘systemtap’ package.
      They include kernel-devel-$(uname -r) and kernel-debuginfo-$(uname -r).

      Reply
      • Len White

        It definitely does not work on CentOS 7.2 with the systemtap package, but it might be because there is no “kernel-debuginfo” package available, only kernel-debug and kernel-debug-devel, which didn’t help.

        Same error as roham, it was easier to grab the kernel SRPM and apply proper patch.

        Reply
        • Reeshma

          Len,

          As per the RedHat bug updates, on CentOS 7.2, the packages kernel-debuginfo and kernel-debuginfo-common are to be downloaded from the repo http://debuginfo.centos.org rather than the usual repos available. Hope that helps.

          Reply
      • Roham Sakhravi

        Hi Reesham,

        Yes I’ve installed all the dependencies, still no luck . Have you tried on 5, and 6 ? Did it work ?

        Reply
        • Reeshma

          Roham,

          This patch works fine on RHEL 7 as the patch is released for systems were ‘/proc/self/mem’ is writable. Its a mitigation against In The Wild (ITW) exploit, which doesn’t affect 5 and 6 versions, as per update from RedHat.

          In RHEL 5 and 6, however, its advisable to manually recompile the kernel to the latest secure one or wait for RedHat to release their updated versions.

          If you need further assistance on kernel compilation, feel free to contact our 24/7 support team here – https://bobcares.com/contact-us/

          Reply
  3. David

    Ubuntu 14
    > sudo apt-get update
    > sudo apt-get dist-upgrade
    > sudo reboot

    I still have the same version of kernel that I had.

    Reply
    • Reeshma

      Hi David,

      Please confirm that you have the latest relevant Ubuntu repositories listed in /etc/apt/sources.list

      Also make sure your system is updated :
      $ sudo apt-get update
      $ sudo apt-get upgrade

      If you still face issues, feel free to contact our 24/7 support team here – https://bobcares.com/contact-us/

      Reply
  4. marc

    Im running centos 6.8 kernel 2.6.32-642.6.1.el6.x86_64
    I run sudo yum install for the following packages
    kernel-devel-$(uname -r)
    systemtap
    but get an error trying to download this one
    kernel-debuginfo-$(uname -r)
    it says no such file
    so i found it on centos rpm mirror and downloaded it. but i still get the error below

    kernel-debuginfo-$(uname -r)
    http[:]//debuginfo.centos.org/6/x86_64/kernel-debug-debuginfo-2.6.32-

    642.6.1.el6.x86_64.rpm
    i went and ran these to get the missing stuff i thought

    missing kernel-debuginfo-common-x86_64
    http[:]//debuginfo.centos.org/6/x86_64/kernel-debuginfo-common-x86_64

    -2.6.32-642.6.1.el6.x86_64.rpm

    Error
    # stap -g update.stp
    semantic error: while resolving probe point: identifier ‘syscall’ at

    update.stp:5:7
    source: probe syscall.ptrace { // includes compat ptrace as

    wellrpm
    ^

    semantic error: no match

    Pass 2: analysis failed. [man error::pass2]

    Reply
    • Reeshma

      Marc,

      If your kernel doesn’t have debuginfo enabled, this workaround not work. The two options you have now is to manually recompile the kernel and patch it or else wait for CentOS to release their secure updates.

      If you need further assistance on kernel compilation, feel free to contact our 24/7 support team here – https://bobcares.com/contact-us/

      Reply
  5. Hikaru Ichijyo

    “If your server is configured for automatic software updates, the server would have already got the new patch installed.”

    First of all, what kind of sysadmin sets up a server to install patches unsupervised?

    Secondly, this is a kernel exploit. Upgrading a kernel *always* requires a reboot. Merely installing the new version does absolutely nothing by itself.

    Reply
    • Reeshma

      Hikaru,

      The update settings may vary with each server setup, hence the reference to ‘If’. Also, the reboot requirement is already mentioned in the next line, looks like you missed it.

      Reply
  6. marc

    How long does the stap -g update.stp command take to execute on the server?

    Reply
    • Reeshma

      Marc,

      It shouldn’t take long. If the command is hung in your server, we may have to check further for compatibility and server kernel versions. If you need further assistance on kernel compilation, feel free to contact our 24/7 support team here – https://bobcares.com/contact-us/

      Reply
  7. Hijarjro

    RHEL 5/6 are not (currently) affected by the PoC or the “in the wild” exploit at this time, nor are forks/derivations that don’t allow you to write to /proc/self/mem
    https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c16

    It’s a caveat your article is missing.

    Reply
    • Reeshma

      Hijarjo,

      Please refer the announcement from RedHat themselves, saying that the following Red Hat Product versions are impacted:

      Red Hat Enterprise Linux 5
      Red Hat Enterprise Linux 6
      Red Hat Enterprise Linux 7
      Red Hat Enterprise MRG 2
      Red Hat Openshift Online v2
      Red Hat Virtualization (RHEV-H/RHV-H)

      Ref: https://access.redhat.com/security/vulnerabilities/2706661

      The patch, however, is limited to RedHat 7 and other updates are still pending.

      Reply
  8. Danny Tosic

    Can this exploitation work in apache user?
    I was tried in my server http://torrent4all.com but it doesn’t work
    And how about fix for CentOS 6.x, 7.x, brother?

    Reply
    • Reeshma

      Danny,

      This exploit affects the Linux kernel and not the web server. So it can affect all servers running the vulnerable kernel, unless they are patched.

      CentOS has still not released the updated versions. But the systemtap patch mentioned in the post should mitigate the issue in CentOS 7. On CentOS 7, the packages kernel-debuginfo and kernel-debuginfo-common are to be downloaded from the repo http://debuginfo.centos.org rather than the usual repos available. For other versions, manual kernel update is the only way out until the vendors release their updated version.

      If you need further assistance on kernel compilation, feel free to contact our 24/7 support team here – https://bobcares.com/contact-us/

      Reply
  9. Joko Hama

    How can I fix it in CentOS 6.8 without rebooting server?

    I am running a site akatorrent.com, so I don’t want to break it

    Reply
    • Reeshma Mathews

      Joko,

      Reboots are necessary after kernel recompilation, to bring the changes into effect. But our experts can handle it with minimum downtime and during off-peak hours. Please contact our 24/7 support team for assistance with vulnerability patching – https://bobcares.com/emergency-server-support/

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *