Posts Tagged exploit

WordPress Update Script – 2.8.6 and WordPress MU 2.8.5.2

Posted by on Monday, 16 November, 2009

New WordPress came out last Friday, Sorry about the delay updating the script.

This script will update all instances of wordpress that are not the most current. Run it as root, it will make backups in /root/wp_upgrades of both databases and files in case things go wrong.

It will determine if its a WordPress or WordPress Multi User and apply the correct fix.

wget http://b.ri.mu/files/wordpress-upgrade-2.8.6.sh
sh wordpress-upgrade-2.8.6.sh

You may need to change the ownership of the wordpress files after install, I will fix this bug and write it into the script in the next couple of versions.

If you have any bugs or problems with it, please let me know.


Chedder Bay Kernel Exploit

Posted by on Saturday, 18 July, 2009

Found at : http://www.jethrocarr.com/index.php?cms=blog:20090718

A new 0-day attack on the Linux kernel has just been released by Brad Spengler called the “Chedder Bay Exploit” which exploits a flaw in the Linux 2.6.30+ kernel.

This exploit is interesting, in that the code doesn’t look particularly broken, but when compiled the compiler optimisations causes the compiled code to have a security hole.

For more technical details on this exploit and further news, check the LWN.net article or use the CVE reference CVE-2009-1897.

From my quick review of the exploit, it appears the attack uses Pulseaudio to bypass Selinux security if it is enabled and then performs an attack against the /dev/net/tun device, allowing a standard user to gain root access.

Not having pulseaudio or the tun kernel module loaded should prevent this exploit from working, although I have not yet had sufficient time to test this since I received the alert announcement around 3am NZ time.

The exploit affects the 2.6.30+ kernel releases and also some of the test kernel 2.6.18 kernel releases by Redhat.

However, all production kernel releases for RHEL/CentOS do not appear to be vulnerable since the change that introduced the security exploit had not been backported yet.

In my tests on CentOS 5.3 with kernel 2.6.18-128.1.16.el5xen on i386/xen, I was unable to trigger the exploit.