Hacker News Reader

Comment by bcl | Hacker News Reader

Looks like it is using suid pulseaudio to load the exploit into the kernel. I don't think RHEL5 systems install pulseaudio by default. Also note that this is a local exploit, you need access to a user account on the system.

ETA: I just tried this on a CentOS5 vmware image (2.6.18-92.1.22.el5) without SELinux and couldn't get it to work.

View on HN

I think the whole pulse audio thing is just for a little entertainment. Check the description in "exploit.c".

My understanding is that it uses pulseaudio to avoid null pointer dereference protection, but the hole is in the tunneling driver.

Any SUID binary which allows library loading would work for this purpose. Normally that's not a security problem, but a combination of other factors has allowed it to become one.

"Normally that's not a security problem" ? PulseAudio allowing arbitrary code loaded into a suid root app via command line parameters is a gaping security hole by itself.

This exploit used a trivial root exploit to setup a deeper kernel level exploit, that can bypass SELinux, hide itself completely, etc.

Reading is fundamental: it's an exploit against 2.6.30.

You're right. RIF. From exploit.c

   for RHEL5 2.6.18 compile with:
   cc -fno-stack-protector -DRHEL5_SUCKS -o exploit exploit.c
   then just ./exploit

Heh, we're both illiterate. More from exploit.c:

   Began port to RHEL5 2.6.18-157:	7/12/09 12:00PM 

   ...

   The buggy commit was backported to a RHEL5 test kernel on April 15th
    (the latest test kernel is still vulnerable and likely without this
    exploit being released, the code would have made it into the next
    RedHat kernel update)
    https://bugzilla.redhat.com/show_bug.cgi?id=495863

That bug report says the first test kernel with that 'fix' applied was kernel-2.6.18-148.el5.

Reply on news.ycombinator.com