The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Is kernel 2.9.34 really vulnerable?

Discussion in 'General Discussion' started by BianchiDude, Sep 10, 2006.

  1. BianchiDude

    BianchiDude Well-Known Member
    PartnerNOC

    Joined:
    Jul 2, 2005
    Messages:
    619
    Likes Received:
    0
    Trophy Points:
    16
    Is kernel 2.6.9-34 really vulnerable?

    WHM tells me:
    Kernels with known vulnerabilities include, but are not limited to, 2.6.9-22 and 2.6.9-34.

    What about 2.6.9-34.0.2 is that one vulnerable?
    I have 2.6.9-34.0.2.ELsmp

    I dont see any known exploits for this kernel on http://www.milw0rm.com/
     
  2. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Yes, it is vulnerable to several security issues and you should upgrade it. I'd suggest you signup to your OS vendor announcement list where they describe the vulnerabilities and bugs that are fixed in new kernel releases.
     
  3. rikgarner

    rikgarner Well-Known Member

    Joined:
    Mar 31, 2006
    Messages:
    75
    Likes Received:
    1
    Trophy Points:
    8
    Location:
    /dev/null
    The fact that you are running 2.6.9-34.0.2.ELsmp gives me the feeling you are running Centos 4.3 ;)

    If so, I can vouch for the upgrade to 2.6.9-42.0.2.ELsmp kernel - I have upgraded to it on several boxes (yum upgrade kernel, after removing kernel* from the /etc/yum.conf excludes, and remembering to put it back after!)

    If anything, the performance of the boxes running it (all Dell PE1850's) seemed to be better :D

    Rich
     
  4. Chew

    Chew Well-Known Member

    Joined:
    Dec 31, 2003
    Messages:
    96
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Maryland
    If you have a multiprocessor kernel already installed.
    Please remember to remove the kernel* from your /etc/yum.conf before performing the upgrade.

    And remember that the command is "yum upgrade kernel-smp"

    After the upgrade is complete verify that your /etc/grub.conf looks something like this
    Code:
    # grub.conf generated by anaconda
    #
    # Note that you do not have to rerun grub after making changes to this file
    # NOTICE:  You have a /boot partition.  This means that
    #          all kernel and initrd paths are relative to /boot/, eg.
    #          root (hd0,0)
    #          kernel /vmlinuz-version ro root=/dev/sda5
    #          initrd /initrd-version.img
    #boot=/dev/sda
    [B]default=0[/B]
    timeout=5
    #splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title CentOS (2.6.9-42.0.2.ELsmp)
            root (hd0,0)
            kernel /vmlinuz-2.6.9-42.0.2.ELsmp ro root=LABEL=/ console=tty0 console=ttyS1,19200n8
            initrd /initrd-2.6.9-42.0.2.ELsmp.img
    
    And replace the kernel* in your /etc/yum.conf after you have verified the upgrade was successful.

    Regards...
     
  5. Stephanie_R

    Stephanie_R Active Member

    Joined:
    Mar 1, 2004
    Messages:
    36
    Likes Received:
    0
    Trophy Points:
    6
    Yep,

    The 2.9.34 kernel is vulnerable to the "procrace" exploits, h00lyshit etc...
    I compiled an exploit on a test server updated to 2.6.9.42.0.2 and it failed, so I think all is good with that one.
    Till the next time :rolleyes:
     
  6. BianchiDude

    BianchiDude Well-Known Member
    PartnerNOC

    Joined:
    Jul 2, 2005
    Messages:
    619
    Likes Received:
    0
    Trophy Points:
    16
    I am trying to see if
    2.6.42 is vulnerable,
    can you confirm you got the same:
    [tester@test tmp]$ ./h00lyshit file

    preparing
    trying to exploit file

    failed: Permission denied

    They state:
    ** if y0u dont have one, make big file (~100MB) in /tmp with dd
    ** and try to junk the cache e.g. cat /usr/lib/* >/dev/null

    What do they mean by
    "and try to junk the cache e.g. cat /usr/lib/* >/dev/null" ?
     
Loading...

Share This Page