Heads Up On Local Root Escalation

Home » CentOS » Heads Up On Local Root Escalation
CentOS 12 Comments

Remember to be especially aware if you have systems that can potentially have code uploaded and run (ftp to httpd vhost or improper php config and file ownership/permissions).

This does not affect el5 … an el6 update is pending.

https://access.redhat.com/security/cve/CVE-2014-0196

12 thoughts on - Heads Up On Local Root Escalation

  • Are there any mitigation steps we can take? I’ve chased down some of the links looking for any, but haven’t had success yet.

    –keith

  • Actually, I was wondering about mitigation along the lines of blacklisting a module, tuning a sysctl parameter, or some other mitigation that wouldn’t require a new kernel. Perhaps such mitigation isn’t even possible with this issue.

    –keith

  • Yeah I’ve not seen any mitigations that would work for CentOS.

    I wonder if a systemtap module would be feasible like that one a few months or so ago.

    For the time being I guess that doubly vigilant is important.

  • Am 12.05.2014 um 20:58 schrieb Akemi Yagi :

    Hi Akemi,

    this would be great – can we push this out? Upstream is delayed (for such vuln).

  • Not specific to this issue, but you might like to look at TPE (kmod-tpe)
    available at elrepo.org.

    http://elrepo.org/tiki/kmod-tpe

    Trusted Path Execution (TPE) is a kernel module that prevents users from executing programs that are not owned by root, or are writable. This effectively blocks users (or compromised accounts) from executing code to exploit vulnerabilities such as this.

    For example, taken from the README:

    * Trusted Path Execution; deny execution of non-root owned or writable binaries

    $ gcc -o exploit exploit.c
    $ chmod 755 exploit
    $ ./exploit
    -bash: ./exploit: Permission denied

    $ dmesg | tail -n1
    [tpe] Denied untrusted exec of /home/corey/exploit (uid:500) by /bin/bash
    (uid:500), parents: /usr/sbin/sshd (uid:500), /usr/sbin/sshd (uid:0),
    /sbin/init (uid:0). Deny reason: directory uid not trusted

  • “This issue does not affect the versions of Linux kernel packages as shipped with Red Hat Enterprise Linux 6.4 EUS and Red Hat Enterprise Linux
    6, because they include backport of upstream commit c56a00a165 that mitigates this issue.”

    2014-05-12 21:13 GMT+03:00 James Hogarth :

  • Am 15.05.2014 um 07:23 schrieb Eero Volotinen :

    cite: “This issue does affect the versions of the Linux kernel packages as shipped with Red Hat Enterprise Linux 6.2 AUS, Red Hat Enterprise Linux 6.3 EUS and Red Rat Enterprise MRG 2, and we are currently working on corrected kernel packages that address this issue.”

  • That should not be an issue for CentOS as CentOS does not support old point releases. The simple answer is if you update to the latest 6.x you are not vulnerable.

    RedHat has to address this because they do have support for staying on a particular point release.

    Peter

  • Am 15.05.2014 um 12:31 schrieb Peter :

    Peter, sure I am with you. Anyway, to complete the big picture its just an additional information and BTW I know people staying on older point releases for various reasons. There are several scenarios in the wild :-)