Results 1 to 13 of 13
  1. #1
    Join Date
    Apr 2003
    Location
    Los Angeles, CA
    Posts
    820

    Linux Kernel 2.6.x PRCTL Core Dump Handling Exploit

    Hi everyone --

    I want to bring this new(ish) kernel exploit to everyone's attention:
    http://www.securiteam.com/exploits/5OP0C0UJ5Y.html

    The bug report is dated 6/19, the exploit is from 7/13. I had the "pleasure" of dealing with it recently on a fairly up-to-date kernel, 2.6.9-40 dated 6/29/06 on RedHat EL. The attacker managed to upload and execute the exploit as the Apache user and then gain root privileges. The point of entry and damages are known to me but I'm don't intent to disclose them unless someone asks. About 1200 binaries and libraries were altered.

    The exploit works on pretty much any new kernel except the newest one, on just about any current distro. A patched kernel 2.6.9-42 is available at http://people.redhat.com/~jbaron/rhel4/RPMS.kernel/ which is not vulnerable to this exploit (verified it myself).

    Check your boxes...

    Here's a sample from another stock kernel:
    luki@hello:~$ uname -a
    Linux hello.xxx.xxx.xxx 2.6.15.4 #1 SMP Fri Feb 10 11:58:25 PST 2006 i686 GNU/Linux
    luki@hello:~$ ls -l
    total 20
    -rwxr-xr-x 1 luki users 12994 2006-07-16 12:35 e
    -rw-r--r-- 1 luki users 1813 2006-07-16 12:35 e.c
    luki@hello:~$ ./e
    Linux Kernel 2.6.x PRCTL Core Dump Handling - Local r00t
    By: dreyer & RoMaNSoFt
    [ 10.Jul.2006 ]
    [*] Creating Cron entry [*] Sleeping for aprox. one minute (** please wait **) [*] Running shell (remember to remove /tmp/sh when finished) ...
    sh-2.05b# whoami
    root
    Pings <1 ms, Unlimited Transfer, Lowest Price: http://localhost/

  2. #2
    Join Date
    Jul 2002
    Location
    Canada, Québec
    Posts
    97
    script not working on 2.6.9-11.EL kernel which appears not to be affected with the problem.

  3. #3
    Join Date
    May 2005
    Posts
    288
    2.6.9-42.EL is considered beta.

    2.6.9-34.0.2.EL is the official kernel that fixes this vulnerability.

    One temporary workaround (as suggested by Matthew Murphy):
    # echo /dev/null > /proc/sys/kernel/core_pattern
    # echo 0 > /proc/sys/kernel/core_uses_pid
    A better workaround would be (my suggestion):
    # echo /tmp/core > /proc/sys/kernel/core_pattern
    # echo 1 > /proc/sys/kernel/core_uses_pid
    You can replace, obviously, "/tmp" for something else. "1" is already the default for core_uses_pid (just including because of the previous exemple).

    DON'T TRUST any workaround related to cron or the /etc/cron.d directory, since using cron is only one possible way to exploit this bug.

  4. #4
    How stable is the 2.6.9-42.EL kernel for you? I have been using it and it has worked great.
    Eleven2 Web Hosting - World-Wide Hosting, Done Right!

  5. #5
    Join Date
    May 2005
    Posts
    288
    Had both API and SELinux related problems here.
    If you have no custom driver and SELinux turned off, I suppose it should be ok (based on my 2 day, only, long experience)

  6. #6
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by SJRHosting
    How stable is the 2.6.9-42.EL kernel for you? I have been using it and it has worked great.


    I have had it crash under load, and on some machines wont even boot.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  7. #7
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by morcego
    2.6.9-42.EL is considered beta.

    2.6.9-34.0.2.EL is the official kernel that fixes this vulnerability.

    One temporary workaround (as suggested by Matthew Murphy):


    A better workaround would be (my suggestion):


    You can replace, obviously, "/tmp" for something else. "1" is already the default for core_uses_pid (just including because of the previous exemple).

    DON'T TRUST any workaround related to cron or the /etc/cron.d directory, since using cron is only one possible way to exploit this bug.

    I have also seen this in a few places:

    echo /var/dump/core_%e.%p >/proc/sys/kernel/core_pattern
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  8. #8
    Join Date
    Aug 2004
    Posts
    142
    servers running on jailed shell (Cpanel) + grsec should be safe though to the original exploit

  9. #9
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by Nazmy
    servers running on jailed shell (Cpanel) + grsec should be safe though to the original exploit

    Why? can be exploited using php/perl. Saying its secure because of grsecurity is a bad statement. it depends on how grsecurity is configured.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  10. #10
    Join Date
    Aug 2004
    Posts
    142
    yeah that's right Steven well I meant the default grsec overstepping config

  11. #11
    Join Date
    Sep 2002
    Posts
    333
    Doesn't the attacker need access to the c compilers for this to work, or not?

  12. #12
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    If they upload a precompiled version, they dont need any c compilers.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  13. #13
    This exploit can easily be used with perl or PHP, just 2 days ago we had one of our servers exploited by this. The account they gained access through had no shell access, and used perl scripts.
    crucialparadigm - Affordable, Reliable, Professional :
    Web Hosting
    24/7 Support • Web Hosting • Reseller Hosting • Cloud/VPS Plans • Dedicated Servers •

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •