You should rebuild your server! Linux CVE-2016-5195 [ Dirty COW ]

Before we get started, let’s set the stage: The referenced Vulnerability is here: https://www.us-cert.gov/ncas/current-activity/2016/10/21/Linux-Kernel-Vulnerability

Why is Linux CVE-2016-5195 [ Dirty COW ] so bad?  

  1. Because what it allows attackers to do – at its very core, this vulnerability is a privilege escalation, which allows a non-root user to write to a file owned by root!  Just think about that and let it soak in – Dr Suess’ book: ‘Oh the Places You’ll Go’  may as well be about hackers.
  2. Because it is easy to exploit – all Proof of Concepts [ executable code ] for exploit are on GIT that can be used + tried can be downloaded here: https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
  3. Because it is in nearly all versions of the Linux Kernel since 2007. Being that is the case; what I have not seen anyone touch on yet – is that any Linux system may in fact be owned already because of this. CVE-2016-5195 is truly a zero day; and [ other than the people who believe it had already been fixed ], there is no telling who had knowledge of this prior to Oct 21st.

I know of one firm that years ago re-built all of their DMZ servers after the server farm had been accidentally fully exposed to the public internet for 15 minutes due to a Firewall misconfiguration and policy push.  Although there was no found evidence of compromise; the only way they could be ABSOLUTELY certain the servers were not compromised during the 15 window was to start over from scratch – rebuild all the servers using vendor files that matched the supplied MD5 hashes.

That Linux server farm rebuild was because of a 15 minute exposure. Many internet facing [ and non-internet facing ] Linux servers have been exposed to this their entire uptime since their initial build. The type of damage from vulnerability CVE-2016-5195 is that an attacker could overwrite system files with their own versions, ( think anything in /bin ) and you’d never know it unless you’ve been a file hashing program (like tripwire) on all your files. To me, if any part of your Linux systems services are in a DMZ; I think  CVE-2016-5195 warrants a rebuild on a patched Kernel. Not just a patch – but a total rebuild if you cannot verify file integrity.

4. Vendors are slow to implement their versions of the patch  – Although Linus Torvalds released a patch: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 Specialized Vendors that implement Linux on their own versions of “appliances” must test the patch with other bundled vendor software and re-release it. Since this was released last Friday,the 21st, RedHat has already confirmed that attackers are using Dirty COW in the wild: http://securityaffairs.co/wordpress/52521/hacking/dirty-cow-exploit.html. I know of one vendor today, Oct 24th that did not have a patch when I queried their TAC support.

My Shares:

Great vid explaining this by r/liveoverflow:  https://www.youtube.com/watch?v=kEsshExn7aE

Patch Info from Ubuntu: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html

Patch Info from RHEL: https://access.redhat.com/security/cve/cve-2016-5195

Patch Info from Debian: https://security-tracker.debian.org/tracker/CVE-2016-5195

Patch Info from SUSE:  https://www.suse.com/security/cve/CVE-2016-5195.html

 

Advertisements
This entry was posted in Linux Security and tagged , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s