Blog Tags: 
security
all

CVE-2016-5195: Dirty COW - Privilege escalation kernel vulnerability

Jeremy Davis - Fri, 2016/10/21 - 09:44 - 14 comments

Thanks to TurnKey community member John Carver it has come to our attention that all existing deployments of TurnKey Linux are potentially vulnerable to CVE-2016-5195. As reported by Andrej Nemec last week on the Red Hat bugtracker "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."

As seems to be the trend these days it has been given the catchy moniker "Dirty COW"and has it's own website and a cute logo:

Dirty COW logo

This privilege escalation vulnerability which dates back nearly a decade was discovered by security researcher, Phil Oester. In an interview he noted that he discovered the vulnerability in the wild when "One of the sites I manage was compromised, and an exploit of this issue was uploaded and executed." The maker of the dirtycow.ninja website has also provided some further details of the vulnerability in a wiki hosted on GitHub.

Debian have pushed out a patched kernel for the stable release (Jessie - the basis of v14.x) as noted by DSA-3696-1. TurnKey's Automatic Security Updates should have already installed this for you. Note that Debian also released a patched kernel for Wheezy (TurnKey v13.x).

If auto updates fix this why do I need to know?

Whilst the TurnKey security updates mechanism auto install all relevant security updates available from Debian, users still need to reboot the server to start using the updated kernel.

To be exploited, this vulnerability requires shell access. So most TurnKey users who do not allow additional OS user accounts should be relatively safe. This is especially the case for v14.x users as service accounts (e.g. www-data) no longer have a shell by default. However, if an attacker were to daisy chain this with other exploits (e.g. a SQL injection) then they could potentially gain full control of your server!

Whilst v14.x (Debian Jessie) and v13.x (Debian Wheezy) users should be ok after a reboot, the news for users of older TurnKey servers is not so good. This vulnerability was introduced into the kernel nearly a decade ago, so all earlier version of TurnKey are vulnerable and WILL NOT be getting a security patch. I strongly urge you to upgrade to the current release ASAP!

How can I check I'm safe?

The easiest way to check that you are ok is to check the kernel version which you are running. Here's an example from a TKLDev server I have running locally: 
root@tkldev ~# uname -v
#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
The fixed versions are noted by Debian's CVE-2016-5195 page. For v14.x you are looking for "3.16.36-1+deb8u2"; while v13.x wants "3.2.82-1". There is no fix for earlier versions other than to upgrade to a supported version.

For users wishing to use TKLBAM to migrate to a current version, please see our docs for a suggested workflow and further considerations.

Resources and further reading:

http://dirtycow.ninja/
https://github.com/dirtycow/dirtycow.github.io/wiki/VulnerabilityDetails
https://lists.debian.org/debian-security-announce/2016/msg00277.html
https://security-tracker.debian.org/tracker/DSA-3696-1
http://www.v3.co.uk/v3-uk/news/2474845/linux-users-urged-to-protect-agai...
http://arstechnica.com/security/2016/10/most-serious-linux-privilege-esc...
http://www.theregister.co.uk/2016/10/21/linux_privilege_escalation_hole/
http://www.itnews.com.au/news/attackers-exploit-ancient-dirty-cow-kernel...

Thanks again to John for bringing this to our attention!

Comments

Keyturns's picture

Keyturns - Sun, 2016/10/30 - 23:03

Hello,

I tried to apply the security updates to patch the CVE-2016-5195 vulnerability but I did not appear to work. I have the Wordpress appliance 14.0 and the result of "uname -v"  is  "#1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)".  I tried the commands you noted here:  https://www.turnkeylinux.org/docs/automatic-security-updates

I ran the command:

turnkey-install-security-updates

and the result ultimately was:

"0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded."

The uname command gave the same result as above.

I also ran:

/usr/sbin/cron-apt

again nothing happened and I have the uname was the same.

I have left the machine running so I guess the 4AM auto update you guys have in there must have failed too.

Any suggestions as to what I can try now?
 

Jeremy Davis's picture

Jeremy Davis - Sun, 2016/10/30 - 23:18
Have you rebooted your server? As I noted above, the security updates should already be installed but you need to reboot to start using the updated kernel. If not, please try that first.

At a glance, it looks like either the update is installed already but just not being used; or you aren't getting updated package information for some weird reason.

If rebooting doesn't make any difference, can you please give me the output of: 

apt-get update
apt-get install linux-image-amd64
Keyturns's picture

Keyturns - Mon, 2016/10/31 - 01:15

A reboot indeed resolved this. When I do a "uname -v" now after the reboot I now get:

#1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)

 

Jeremy Davis's picture

Jeremy Davis - Mon, 2016/10/31 - 02:23
Glad to hear that did the trick! :)
VladGets's picture

VladGets - Fri, 2016/11/04 - 12:02

Cool

What the side of the page?

Scott's picture

Scott - Mon, 2016/11/14 - 23:56

Would appreciate some help on this .. got a turnkey nginx server (turnkey-nginx-php-fastcgi-14.0-jessie-amd64)

uname -v returns:

#1 SMP Debian 3.16.7-ckt11-1+deb8u5 (2015-10-09)

Have also run 

turnkey-install-security-updates

And 

/usr/sbin/cron-apt

And rebooted -but still showing the older kernel.

The following was also no help - it all reports up to date.

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

This also indicates nothing to update:

apt-get install linux-image-amd64

output is:

Reading package lists... Done
Building dependency tree
Reading state information... Done
linux-image-amd64 is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

 

Confused ???   Scott

Scott

www.rakata.co.uk

Jeremy Davis's picture

Jeremy Davis - Tue, 2016/11/29 - 07:41
Apologies, I missed your comment here sorry.

That does seem really weird and TBH I don't understand. Are you getting any errors or warnings when you run apt-get update?

Also what is the output from: 

apt-cache policy linux-image-amd64
Scott's picture

Scott - Wed, 2016/11/30 - 12:41

apt-get

Get:1 http://security.debian.org jessie/updates InRelease [63.1 kB]
Get:2 http://security.debian.org jessie/updates/main amd64 Packages [328 kB]
Ign http://http.debian.net jessie InRelease
Ign http://archive.turnkeylinux.org jessie-security InRelease
Get:3 http://security.debian.org jessie/updates/contrib amd64 Packages [2506 B]
Get:4 http://security.debian.org jessie/updates/contrib Translation-en [1211 B]
Hit http://http.debian.net jessie Release.gpg
Get:5 http://security.debian.org jessie/updates/main Translation-en [173 kB]
Ign http://archive.turnkeylinux.org jessie InRelease
Hit http://http.debian.net jessie Release
Hit http://archive.turnkeylinux.org jessie-security Release.gpg
Hit http://http.debian.net jessie/main amd64 Packages
Hit http://http.debian.net jessie/contrib amd64 Packages
Hit http://archive.turnkeylinux.org jessie Release.gpg
Hit http://http.debian.net jessie/contrib Translation-en
Hit http://http.debian.net jessie/main Translation-en
Hit http://archive.turnkeylinux.org jessie-security Release
Hit http://archive.turnkeylinux.org jessie Release
Hit http://archive.turnkeylinux.org jessie-security/main amd64 Packages
Hit http://archive.turnkeylinux.org jessie/main amd64 Packages
Ign http://archive.turnkeylinux.org jessie-security/main Translation-en
Ign http://archive.turnkeylinux.org jessie/main Translation-en
Fetched 568 kB in 3s (156 kB/s)
Reading package lists... Done

and apt-cache

linux-image-amd64:
  Installed: 3.16+63
  Candidate: 3.16+63
  Version table:
 *** 3.16+63 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages
        100 /var/lib/dpkg/status

I noticed there are a few Ign's on apt-get - I'd always treated that as a warning - is that an issue?

Scott

www.rakata.co.uk

Jeremy Davis's picture

Jeremy Davis - Thu, 2016/12/01 - 03:24
Your apt-get update output looks ok and the kernel meta-package matches mine too?! Perhaps double check for the actual kernel package itself: 
apt-cache policy linux-image-3.16.0-4-amd64
If that isn't showing the right version (i.e. 3.16.36-1+deb8u2) as installed/installable, then the only thing I can think of is perhaps you are being directed to a "bad" Debian mirror which is out of date?

The one we use by default, should redirect you to the best mirror. However, in your case, perhaps it's not for some reason? So perhaps try explicitly using one of the Debian mirrors (don't change the TurnKey mirror, just the entries that are http.debian.org).

To do that have a look at your apt sources file(s). The default top level sources file is /etc/apt/sources.list but by default in TurnKey we leave that empty and instead it is configured in 2 separate files within /etc/apt/sources.list.d/. FWIW apt will read any file within that directory which has a .list file extension. By default TurnKey provides a general sources.list (/etc/apt/sources.list.d/sources.list) and a security sources list (/etc/apt/sources.list.d/security-sources.list). Initially just adjust the general list. But once you have resolved the immediate issue, I urge you to also update the security list (that's what the auto secupdates uses).

Obviously you'll need to run "apt-get update" once you've updated your sources.list. I also recommend that initially you just check for the versions available (i.e. apt-cache policy).

As for your question re the "Ign"s, TBH I'm not 100% sure, but AFAIK it is as you say; a warning. I see them lots on my (Debian) desktop as I'm Australian and use the en_AU locale. But as "Australian English" (at least in more formal written form) is essentially a subset of British and US English, nobody makes any specific translations for en_AU so when apt-get update checks for Australians translations they always return "Ign".

Scott's picture

Scott - Thu, 2016/12/01 - 11:45

Output from : apt-cache policy linux-image-3.16.0-4-amd64

linux-image-3.16.0-4-amd64:
  Installed: 3.16.36-1+deb8u2
  Candidate: 3.16.36-1+deb8u2
  Version table:
 *** 3.16.36-1+deb8u2 0
        500 http://security.debian.org/ jessie/updates/main amd64 Packages
        100 /var/lib/dpkg/status
     3.16.36-1+deb8u1 0
        500 http://http.debian.net/debian/ jessie/main amd64 Packages

So that in fact looks good.  Strange then that uname -v should report something else.

This is stretching my linux experience, so I'm guessing but is it possible apt thinks its install but in fact it hasn't been applied properly ?

As the apt-cache looks good I have followed up on the sources - but the lists look ok as best I can tell.

Thanks for the support on this.  

 

Scott

www.rakata.co.uk

Jeremy Davis's picture

Jeremy Davis - Thu, 2016/12/01 - 22:39
uname gives info about the kernel in use. apt gives info about what's installed.

So you have the right kernel installed, it's just your system isn't using it.

Normally a reboot should resolve that. But you said that you had already rebooted right?!

Maybe for some reason your server was a bit slow to update, so when you rebooted before the new kernel hadn't installed. But at some point since it has installed the update and just needs a reboot now!?

Scott's picture

Scott - Fri, 2016/12/02 - 18:32

I'll reboot it again when I get a chance.

Scott

www.rakata.co.uk

Scott's picture

Scott - Tue, 2017/01/31 - 12:56

As an update > a shutdown and reboot didn't help.

I've run some other tests though and the system is reported as safe.   

Weird.   When I get a chance I'll try a  build using the latest iso.  

Scott

www.rakata.co.uk

Jeremy Davis's picture

Jeremy Davis - Sat, 2017/02/18 - 06:17
Hey Scott. Some others have reported another kernel related issue and I thought it may be related to your experience? So I thought I'd check back in with you.

Out of interest, are you using LVM in your install? FWIW it's default on OVA/VM builds and optional on ISO install. It seems to be a factor in that other thread.

Long story short, here's something you could try:

See what device your boot directory/partition is on. Check fdisk and look for the entry that has the boot flag set (i.e. has a '*' under 'Boot') e.g.: 

[...]
Device     Boot  Start      End  Sectors  Size Id Type
/dev/sda1  *      2048   499711   497664  243M 83 Linux
[...]
I'll assume that it's /dev/sda1 (most likely it is...). The fix requires (re)installing grub to the relevant root device. I.e. if you have a boot partition on /dev/sda1 then the device to install to is /dev/sda. So run this (substituting your specific device if it's not /dev/sda): 
grub-install /dev/sda
Double check all seems well by checking that the grub config file exists: 
ls /boot/grub/grub.cfg
If either (or both) of those commands give an error, try manually creating the /boot/grub directory first ('mkdir /boot/grub'), re-run grub-install and recheck for the grub.cfg. Once you have confirmed all appears well, then reboot.

Please let me know if you continue to have issues and/or any of that doesn't make sense.

Pages

Add new comment