Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 266
  • Last Modified:

Assess most serious Linux privilege escalation bug


After reading the above, I still can't identify which flavor of Linux it affects:
RHEL, Ubuntu, CentOS, Mandrake, Debian, ...

Are custom Linuxes like those used in Cisco IOS or NX-OS (Nexus), Bluecoat appliances (Ubuntu), Androids,
Juniper ScreenOS & JunOS, photocopiers/MFPs affected?  How do we determine if they are affected?

I'm also trying to determine the Linux variants without login to the OS/device: how can I do it?  Do provide
the exact commands (say using nmap) ?
  • 6
  • 5
  • 3
  • +2
8 Solutions

All of them.  It is an old nine year bug.


All of them including Android.

Read more https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years

The major distributions have fixes or will have fixes shortly.
btanExec ConsultantCommented:
Ref - http://dirtycow.ninja/

The Linux kernel since version 2.6.22 contains this bug.
The Linux kernel versions 4.8.3, 4.7.9, and 4.4.26 address this vulnerability. See below.
Redhat - https://access.redhat.com/security/vulnerabilities/2706661
Debian - https://security-tracker.debian.org/tracker/CVE-2016-5195
Ubuntu - http://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-5195.html
SUSE - https://www.suse.com/security/cve/CVE-2016-5195.html

There is no confirmation that Android or specific if those listed is affected by this CVE even though they are using Linux based OS.  The best is to reconfirmed with those providers. The Redhat suggested a detection (sh) script

Some have share the self-check (not using nmap) but likely can wait to see if any other will contribute to various source to detect this CVE.
How to test if you are vulnerable ?

1) Download and compile the PoC
root@server# curl https://raw.githubusercontent.com/dirtycow/dirtycow.github.io/master/dirtyc0w.c > dirtyc0w.c
root@server# gcc -lpthread dirtyc0w.c -o dirtyc0w

2) Copy the binary in some user directory
root@server# cp dirtyc0w /home/some_user/

3) Create read-only root owned file
root@server# echo "This is a test file" > /home/some_user/foo
root@server# chmod 0404 /home/some_user/foo

4) Execute the exploit with ‘some_user’ and try to modify foo file
root@server# su - some_user -s /bin/bash
some_user@server# ./dirtyc0w foo m00000000000000000

5) Finally check if the file foo is modified:

If you get this:
root@server# cat /home/some_user/foo

Then you are VULNERABLE.

root@server# cat /home/some_user/foo
This is a test file

Then you are SAFE
more on Q2

IOS runs on a non preemptive kernel that is quite different from linux.
it is fairly possible that the virtual ios appliances they provide for training are impacted through.

android did have the bug at some point ( i think 4.2 was the one ). no idea about other versions but i'd assume yes. given the rest of android security, that does not make much of a difference.

junOS is (Free)BSD-based. most definitely not plagued by such bugs given the quality of the code compared to linux's

i'm unsure about screenos but it is possible

if bluecot is ubuntu based, i assume they will patch soon since ubuntu did

i dont't think you need to care about escalations on a photocopier on which ino one has a non-privileged account anyway


nmap -Pn -O host
obviously this does not always work

you may also try finger if available or more realistically SNMP

if you have a deployment tool available can't you use that to run a script that reports the os version ?


it's funny how the world of security works nowadays. people talk about 0-day but they actually behave in such a way they get affected by +9years bugs...
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

sunhuxAuthor Commented:

Looks like F5 (LTM Loadbalancer & GTM) that we used & Avaya are RHEL based, so they're

What about Thales HSM ?
sunhuxAuthor Commented:
Internet-facing devices are the first we need to look into, so the F5 devices, external
firewall (ie Juniper) & external router (Cisco IOS) are the ones that come to mind
sunhuxAuthor Commented:
So questions are:
a) if we use 2nd latest version of F5 (LTM GTM) OS, are we affected (based on the kernel
     versions BTan provided above)
b) are the CIsco IOS 12.x (also 2nd latest version) affected?
c) are VMware ESXi 5.1 affected?
sunhuxAuthor Commented:
Thing is we currently has MS SCCM deployment tool which I don't think it
could centrally login (or remotely issue a command to) UNIX/Linux based devices
btanExec ConsultantCommented:
The affected list are (https://bobcares.com/blog/dirty-cow-vulnerability/)
-Red Hat Enterprise Linux 7.x, 6.x and 5.x
-CentOS Linux 7.x, 6.x and 5.x
-Debian Linux wheezy, jessie, stretch and sid
-Ubuntu Linux precise (LTS 12.04), trusty, xenial (LTS 16.04), yakkety and vivid/ubuntu-core
-SUSE Linux Enterprise 11 and 12

1) See F5 version and build. CentOS Linux 7.x, 6.x and 5.x are affected

12.0.0 - 12.1.1      CentOS 6.5, Linux Kernel 2.6.32 (64-bit kernel only)
11.1.0 - 11.6.1      CentOS 5.4 - 6.4, Linux Kernel 2.6.32 (64-bit kernel only)
11.0.0                      CentOS 5.4 - 6.0, Linux Kernel 2.6 (64-bit kernel only)
10.1.0 - 10.2.4      CentOS 5.4, Linux Kernel 2.6 (64-bit capable platforms run a 64-bit kernel)

2) Cisco is not Linux as-is and I doubt it is affected, or on any other common OS It may well be entirely custom. There is mentioned of may be likely QNX based (a monolithic kernel) which is UNIX-like. Have to hear from Cisco on their own check instead. Or try to telnet into the box and do a "uname -a command". If the kernel version displayed 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

3) VMWare in older version has the vmkernel is running on the bare computer, and the Linux-based service console runs as the first virtual machine. Since then, it dropped development of ESX at version 4.1, and now uses ESXi, which does not include a Linux kernel. It is likely to be more towards Unix-like and thus may not be affected.
i think vmware is but i'm usure about which versions ( given the above ). real time kernels are not.
btanExec ConsultantCommented:
For VMware,  it dropped development of ESX at version 4.1, and now uses ESXi, which does not include a Linux kernel, though I will say there may still be reuse in its  VMKernel  on modules derive from modules used in the Linux kernel. http://blogs.vmware.com/vsphere/2013/06/its-a-unix-system-i-know-this.html

The VMware FAQ mentions that ESX has both a Linux 2.4 kernel and vmkernel – hence confusion over whether ESX has a Linux base. Some key points
- An ESX system starts a Linux kernel first, but it loads vmkernel (also described by VMware as a kernel), which according to VMware 'wraps around' the linux kernel, and which (according to VMware Inc) does not derive from Linux.
- The ESX userspace environment, "Service Console" (or as "COS" or as "vmnix"), derives from a modified version of Red Hat Linux, (Red Hat 7.2 for ESX 2.x and Red Hat Enterprise Linux 3 for ESX 3.x).
- VMware ESXi, a smaller-footprint version of ESX, does not include the ESX Service Console

So if we err on the safe side, based on ESX's Linux version and Red Hat version which is so much older version is not in the list of affected. But I still see instead of assumption, the provider need to address it on public concerns via their advisories
sunhuxAuthor Commented:
Last few clarifications from me (hopefully):

Is there any tool or VA scanner that could detect this vulnerability currently
(other than the RHEL script & manually login to check the kernel version)?

Are the following versions of products vulnerable:
F5 BIGIP:                 11.6.1 HF1
Bluecoat proxy:
an appliance    :      Ubuntu 12.04.1 LTS
sunhuxAuthor Commented:
One security bulletin that we subscribed to listed the following:

Last few clarifications from me (hopefully):

Ubuntu/Debian distro versions that are earlier than the following are affected:

•         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  <== is our 12.04.1 LTS affected?
•         3.16.36-1+deb8u2 for Debian 8
•         3.2.82-1 for Debian 7
•         4.7.8-1 for Debian unstable

RedHat product versions that are impacted are as per follows:
•      Red Hat Enterprise Linux 5  <== F5 BIGIP 11.6.1 HF1 is under this?
•      Red Hat Enterprise Linux 6
•      Red Hat Enterprise Linux 7
•      Red Hat Enterprise MRG 2
•      Red Hat Openshift Online v2
is our 12.04.1 LTS affected?

"uname -a" will give you the current running kernel

"dpkg -l | grep -i linux-image | tail -n 1" will provide the last installed kernel

both should agree but if the latter is more up to date than the first, reboot.

note that older unlisted debian systems are most likely vulnerable


Is there any tool or VA scanner that could detect this vulnerability currently

not remotely unless you can run the checker over ssh using an unprivileged account


note that unless you have a machine on which non privileged and potentially feeling hacky users can connect, you should not care.

note that if you do, you should rethink your security policies rather than relying on CVEs... or just don't bother since you're not more insecure in any way as last month.

also note that there are multiple other ways to perform the same kind of privileges escalation on recent kernels anyway, and both linux and windows have a wealth of both known and unknown similar holes, not to speak about openssl, gnu's libc, and the likes.

basing security on CVEs only is just plain dumb, and a good security officer should hardly be phased by any of them.
btanExec ConsultantCommented:
For the tool, only the script or the PoC (dirtyc0w.c) codes as I last posted in ID: 41854886This CVE-2016-5195 will eventually be part of the AV but for now yet to have any besides those I shared with you. Probably the C codes can be converted to Python script

For F5  11.6.1, it is based on CentOS 6.4, Linux Kernel 2.6.32 (64-bit kernel only) so it should be affected. Note that F5  11.1.0 - 11.6.1 is from CentOS 5.4 - 6.4, Linux Kernel 2.6.32 (64-bit kernel only)

For Bluecoat, I suggest if you can run "show current-release verify-rpm" to see the kernel and check as all Linux 7.x, 6.x and 5.x are affected

For Ubuntu 12.04.1 LTS, it is stated only Ubuntu Linux precise (LTS 12.04 and below) affected. You should update it  https://www.ubuntu.com/usn/usn-3105-2/
Rich RumbleSecurity SamuraiCommented:
Ok first, this is not a remotely executable bug, your linux device will have to download or have a file uploaded to it, then execute it. If your server or other device is not in that habit, then you don't have to worry about this bug yet... The bug will morf and get more "features" soon, but for now, unless your linux device is running files that anyone uploads, this cannot be exploited.

To the questions, 1, has been addressed by Sunhux, but I would like to mention that RHEL 5/6 are not affected yet, however this may be changing: https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
That is not to say that RHEL 5 and 6 won't get affected, currently they are not, but watch that PoC list and I'm sure they will pop up soon.

Android is affected, Cisco-IoS may be affected, however most network hardware isn't in the habit of running binaries from just anyone, it's not too big a worry.

While this bug is "bad" it's not as bad as it has been made out to be, it is not easily exploited like shellshock, or heartbleed.
btanExec ConsultantCommented:
On my previous post it should have been ID: 41855291

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 6
  • 5
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now