31 ms·
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
by bcl 17y ago
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.
- notaddicted 17y agoI think the whole pulse audio thing is just for a little entertainment. Check the description in "exploit.c".
- nailer 17y agoMy understanding is that it uses pulseaudio to avoid null pointer dereference protection, but the hole is in the tunneling driver.
- jmillikin 17y agoAny 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.
- yosh 17y ago"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.
- calambrac 17y agoReading is fundamental: it's an exploit against 2.6.30.
- bcl 17y agoYou'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
- calambrac 17y agoHeh, 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.