Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Dirty COW Vulnerability - Kernel Update Oct 21st
New on LowEndTalk? Please Register and read our Community Rules.

Dirty COW Vulnerability - Kernel Update Oct 21st

mehargagsmehargags Member
edited October 2016 in General

I hope everyone is patched up for this very serious vulnerability called Dirty COW disclosed on October 19, 2016.

It is a privilege escalation vulnerability in the Linux Kernel existing since Kernel v2.6.22 thru which an attacker may gain write access to any file they can read, and then increase their privileges system-wide.

DO posted a nice How To Protect Your Server Against the Dirty COW Linux Vulnerability

Check your kernel version.
uname -rv

Anything below the versions stated below are 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

##CentOS and Redhat are yet to release a patch fix.

My biggest concern is with OpenVZ Containers... What is the remedy for OVZ as they are all stuck at Kernel 2.6?

Thanked by 2deadbeef mik997
«134

Comments

  • FlapadarFlapadar Member
    edited October 2016

    @mehargags said:

    My biggest concern is with OpenVZ Containers... What is the remedy for OVZ as they are all stuck at Kernel 2.6?

    My understanding is that this exploit cannot be used for container or virt breakout. I've also heard RHEL 6 is unaffected.

  • rivermiguerivermigue Member, Provider

    Affected kernel versions in RHEL6 are located in the DO post mentioned by the OP. RHEL 6 is affected.

    https://access.redhat.com/sites/default/files/rh-cve-2016-5195_1.sh

    Att. Miguel Rivera
    TempleServers.com Debian WebHosting | Nginx | Apache | Daily backups
    KVM and OpenVZ virtualization in Germany and Canada. A registered trademark of Breinz S.A de C.V NIT: 0614-051216-105-5

  • FoulFoul Member
    edited October 2016

    Partial Mitigation Resolution

    https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13

    Petr Matousek 2016-10-19 12:16:23 EDT
    Please note that this mitigation disables ptrace functionality which
    debuggers and programs that inspect other processes (virus scanners)
    use and thus these programs won't be operational.
    
    Also this mitigation works against the In The Wild (ITW) exploit we are aware of but most likely does not mitigate the issue as a whole.
    
    To mitigate the issue:
    
    
    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 and matching kernel-devel packages
    
    3) Run the "stap -g [filename-from-step-1].stp" command as root.
    
    If the host is rebooted, the changes will be lost and the script must be
    run again.
    
    
    Alternatively, build the systemtap script on a development system with
    "stap -g -p 4 [filename-from-step-1].stp", distribute the resulting
    kernel module to all affected systems, and run "staprun -L <module>" on those.
    When using this approach only systemtap-runtime package is required on
    the affected systems. Please notice that the kernel version must be the same
    across all systems.
    
  • KuJoeKuJoe Member, Provider

    If you're running KernelCare then this was patched yesterday for most kernels: https://www.cloudlinux.com/kernelcare-blog/entry/dirty-cow-vulnerability-the-fix-is-coming

    -Joe @ SecureDragon - LEB's Powered by Wyvern in FL, CO, CA, IL, NJ, GA, OR, TX, and AZ
    Need backup space? Check out BackupDragon
  • @KuJoe said:
    If you're running KernelCare then this was patched yesterday for most kernels: https://www.cloudlinux.com/kernelcare-blog/entry/dirty-cow-vulnerability-the-fix-is-coming

    So does that mean even if my OVZ VPS is running :
    2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

    I am not affected ?

    Just got a ticket reply from my provider saying "OpenVZ is not affected by this. You are safe."

    What does that mean ? If its a kernel level exploit and some gains access to my public web app, he cannot gain privileged access ?

    I seriously doubt the "layers" we are talking about

  • Awmusic12635Awmusic12635 Member, Provider

    @mehargags

    Well also if the provider is using kernel care the actual kernel patch version wouldn't show.

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

  • mehargags said: So does that mean even if my OVZ VPS is running : 2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

    I dont think kernelCare provide kernel patching for Proxmox :)

    I am no longer active here, find me at https://talk.lowendspirit.com

  • Awmusic12635Awmusic12635 Member, Provider
    edited October 2016

    @AnthonySmith said:

    mehargags said: So does that mean even if my OVZ VPS is running : 2.6.32-44-pve #1 SMP Mon Jan 25 13:03:39 CET 2016

    I dont think kernelCare provide kernel patching for Proxmox :)

    They do, we use it

    Thanked by 1netomx

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

  • deadbeefdeadbeef Member
    edited October 2016
    $ ./rh-cve-2016-5195_1.sh 
    Your kernel is 4.6.4-1.el7.centos.x86_64 which is NOT vulnerable.
    
    # ./rh-cve-2016-5195_1.sh 
    Your kernel is 4.8.1-1.el7.centos.x86_64 which is NOT vulnerable.
    

    Confused :o Shouldn't they be vulnerable?

    *Edit: For the second one, I suppose I misunderstood the "centos has not released a fix yet" part.

  • Awmusic12635 said: They do, we use it

    excuse me, I am eating a hat right now.

    Thanked by 1netomx

    I am no longer active here, find me at https://talk.lowendspirit.com

  • eva2000eva2000 Member
    edited October 2016

    @deadbeef said:
    $ ./rh-cve-2016-5195_1.sh
    Your kernel is 4.6.4-1.el7.centos.x86_64 which is NOT vulnerable.

    # ./rh-cve-2016-5195_1.sh
    Your kernel is 4.8.1-1.el7.centos.x86_64 which is NOT vulnerable.

    Confused :o Shouldn't they be vulnerable?

    *Edit: For the second one, I suppose I misunderstood the "centos has not released a fix yet" part.

    the detection script is too basic it just checks against known centos/rhel provided kernel versions to see if you're vulnerable. If you use elrepo or other non-rhel/centos provided kernel versions then the detection doesn't work

    standard centos 7 kernel

    ./rh-cve-2016-5195_1.sh
    Your kernel is 3.10.0-327.36.1.el7.x86_64 which IS vulnerable.
    Red Hat recommends that you update your kernel. Alternatively, you can apply partial
    mitigation described at https://access.redhat.com/security/vulnerabilities/2706661 .
    

    elrepo 4.7.5kernel isn't detected as vulnerable because the detection script isn't looking for that kernel version

    ./rh-cve-2016-5195_1.sh
    Your kernel is 4.7.5-1.el7.elrepo.x86_64 which is NOT vulnerable.
    

    similarly linode fixed 4.8.3 kernel for this flaw isn't detected

    ./rh-cve-2016-5195_1.sh
    This script is only meant to detect vulnerable kernels on Red Hat Enterprise Linux 5, 6 and 7.
    
    Thanked by 1deadbeef
    * Centmin Mod Project (HTTP/2 support + ngx_pagespeed + Nginx Lua + Vhost Stats)
    * Centmin Mod LEMP Stack Quick Install Guide
  • @Awmusic12635 said:
    Well also if the provider is using kernel care the actual kernel patch version wouldn't show.

    So what Kernel Version are you using exactly ?

    I guess the providers should mail all customers informing them as there will be many who will feel "unsafe" not being able to go past v2.6 after an apt-get upgrade.

  • Awmusic12635Awmusic12635 Member, Provider

    mehargags said: So what Kernel Version are you using exactly ?

    Looks like

    kpatch-description: 8;2.6.32-47-pve_2.6.32-179

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

  • rincewindrincewind Member
    edited October 2016

    If you want to test for the vulnerability, PoCs is a better resource.

    The mitigation code that I have seen so far block against the one known exploit in the wild that uses /proc/self/mem.

    https://github.com/scumjr/dirtycow-vdso escapes containers and SELinux.

    Thanked by 1deadbeef
  • @mehargags said:

    thanks for heads up - all patched :)

  • RazzaRazza Member
    edited October 2016

    Useing Grsecurity kernel test patch's, no sure when this was fixed, but the Grsecurity patched kernel i built on the 7 Oct using kernel 4.7.6, i've tried ever Poc none of them seem to be working.

    Edit

    It seem that one's based on /proc/self/mem are non working, but one's useing PTRACE_POKEDATA seem to still work fine.

  • kaflokaflo Member
    edited October 2016

    @Awmusic12635 said:
    kpatch-description: 8;2.6.32-47-pve_2.6.32-179

    sea2 says 2.6.32-43-pve #1 SMP Tue Oct 27 09:55:55 CET 2015

    so it's still vulnerable?

  • Awmusic12635Awmusic12635 Member, Provider

    @kaflo said:

    @Awmusic12635 said:
    kpatch-description: 8;2.6.32-47-pve_2.6.32-179

    sea2 says 2.6.32-43-pve #1 SMP Tue Oct 27 09:55:55 CET 2015

    so it's still vulnerable?

    I believe I said this earlier, kernelcare doesn't show the new version via the uname command. You can only see what the live patched version is by running the kernel care command, which only works on the host node.

    Thanked by 1kaflo

    Subnet Labs, LLC Contact Us Deploy to: Seattle, Dallas or NYC
    Impact VPS | Cloud Servers | Storage Servers | Impact Shared | Shared Hosting

  • rivermiguerivermigue Member, Provider

    Interesting comment taken from https://bugzilla.redhat.com/show_bug.cgi?id=1384344

    The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and > 6 out of the box because on one side of the race it writes to /proc/self/mem, but >/proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.

    Att. Miguel Rivera
    TempleServers.com Debian WebHosting | Nginx | Apache | Daily backups
    KVM and OpenVZ virtualization in Germany and Canada. A registered trademark of Breinz S.A de C.V NIT: 0614-051216-105-5

  • I might be completely barking up the wrong tree but I had a further look in to it myself, this seems very similar to the XSA that caused amazon to reboot not so long ago with the big embargo on Xen.

    I am no longer active here, find me at https://talk.lowendspirit.com

  • @rivermigue said:
    Interesting comment taken from https://bugzilla.redhat.com/show_bug.cgi?id=1384344

    The in the wild exploit we are aware of doesn't work on Red Hat Enterprise Linux 5 and > 6 out of the box because on one side of the race it writes to /proc/self/mem, but >/proc/self/mem is not writable on Red Hat Enterprise Linux 5 and 6.

    There's a different flavor of exploit in the wild that does not use /proc/self/mem, but relies on ptrace instead. @Razza reported above that the ptrace-variants seem to be still working.

  • Am I right in thinking this isn't a vulnerability that can be exploited over the net? For pretty much all the servers I run, I'm the sole command line user.

  • ricardo said: Am I right in thinking this isn't a vulnerability that can be exploited over the net? For pretty much all the servers I run, I'm the sole command line user.

    I believe the exploit requires some sort of shell access even if limited or at least the ability to exec something and access to 'a file'

    I am no longer active here, find me at https://talk.lowendspirit.com

  • @rincewind said:
    https://github.com/scumjr/dirtycow-vdso escapes containers and SELinux.

    I need to congratulate the author of that page for the excellent title chosen.

    Thanked by 1rincewind
  • What baffles me is the absence of a proper fix. If the problem has been disclosed, why is there no effective patch yet? Is it a design issue and can't be patched?

  • deadbeef said: What baffles me is the absence of a proper fix.

    I thought that most distros had the kernel patched and you just need to do an update. It's the routers and other devices that are a problem. You might like the El Reg article, Dirty Cow Explained.

    Thanked by 2deadbeef mikho
  • @Ole_Juul said:
    I thought that most distros had the kernel patched and you just need to do an update.

    Idk, the guys above said that the patch is for the specific implementation found on the wild and different implementations still exploit this fine. I.e. the root cause is unfixed.

    It's the routers and other devices that are a problem.

    Don't you need a local account to use this exploit?

  • "although it is a local privilege escalation bug, remote attackers can use it in conjunction with other exploits that allow remote execution of non-privileged code to achieve remote root access on a computer"

    arstechnica.com/security/2016/10/most-serious-linux-privilege-escalation-bug-ever-is-under-active-exploit/

    Thanked by 1deadbeef
  • rincewindrincewind Member
    edited October 2016

    deadbeef said: Is it a design issue and can't be patched?

    This specific bug is a race condition with copy-on-write pages, but the real problem is the madvise(., MADV_DONTNEED) call which is a design issue.

    ricardo said: Am I right in thinking this isn't a vulnerability that can be exploited over the net?

    The first exploit known was an SQL injection sent over the net. The real problem is that it is almost impossible to block - it makes a mockery of all the usual protection mechanisms.

    Thanked by 1deadbeef
  • SQL injection

    As I understand it, it's going to require a lapse in security like that (where the system is likely to get owned anyway), or a mechanism that allows a user to create a file and execute it.

    Thanked by 1deadbeef
Sign In or Register to comment.