New Zealand Linux

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.

According to http://arstechnica.com/open-source/news/2009/04/linux-foundation-says-its-time-to-ditch-microsofts-fat.ars

Because Microsoft and TomTom have settled their dispute. Apparently TomTom used the Linux kernel for their GPS, which contains FAT support which is a no-no slap in the face for M$.

TomTom Counter sued M$ based on the fact that they stole some navigation like stuff. TomTom now has paid to license Microsoft’s patents, including those covering FAT, However they are going to weed it out and remove it in the next couple of years.

Although the settlement has ended the conflict between Microsoft and TomTom, questions still remain about the implications for FAT in the broader Linux ecosystem. Microsoft has previously stated that this lawsuit represents an isolated issue and that the company does not intend to broadly sue Linux users. Upstream kernel developers could potentially adopt TomTom’s code changes in order to avoid future patent disputes with Microsoft over FAT.

But being a paranoid people we (linux users) are they are going to try weeding such old and out dated filesystems out of the kernel in the not too distant future.

In the world of operating system design, a lot of critical decisions are made by the developers concerning how the system uses the limited resources available to it.

Part of the design pertains to memory, and making use thereof. Most modern operating systems go by the theory that “free” can be equated with wasted when it comes to RAM utilisation.

For this reason Linux attempts to use your unused memory for one of two things, disk cache or virtual memory (aka swap).

A disk cache holds files in memory as they are read off the disk (usually also handling tasks like pre-fetching file contents before they’re requested).

On the other hand, virtual memory is (at least perceived to be) used primarily when there is not enough memory available.

Linux also makes use of virtual memory by proactively swapping out inactive tasks once a threshold of inactivity has been reached.

On the face of things this seems a very valid thing to do, after all who wants an application that only does anything once a day slurping up RAM for the rest of the time. Why not swap it out to virtual memory until it needs to do something?

The problem for interactivity is that Linux is not very granular or intelligent about how it manages the inactive tasks, often switching out tasks like instant messenger applications.

Often the whole point of leaving an application open all the time is to allow instant access to it, and swapping it out to disk effectively kills that benefit by creating a delay while you wait for the pages to be swapped back into memory.

Frequently swapping back an inactive application triggers the threshold for swapping out other active applications like the web browser.

The end result could pan out something like this; you’re reading a web page, when you get a message in your IM application, it swaps into ram to notify you, you pause to look at the message long enough for the kernel to decide your browser is inactive, you continue reading your web page, “activating” and swapping your browser back in and then decide to reply to the message, swapping your “inactive” IM program back in.

That’s a lot of disk activity, considering that you may well have enough RAM to contain both applications at the same time.

I’ve chosen a ridiculous worst case scenario to indicate something that might happen if you live in a lake of semi-frozen treacle and it takes 5 minutes for you to change from one application to another, but it’s still quite possible to end up in scenarios like this in the real world without needing to be submerged in viscous goo.

Thankfully the developers of Linux made provision for end users to easily change this behaviour using the /proc virtual filesystem. Here’s how to do it…

echo 0 > /proc/sys/vm/swappiness

The usual default value of swappiness is 60, valid values are from 0 (no pro-active swapping) to 100 (high tendency to swap out inactive tasks).

My opinion is that swapping out tasks before virtual memory is required is generally unhelpful on desktop computers unless you have VERY fast virtual memory so I set swappiness to 0, but using the example and information above you should be able to figure out how to tune swappiness to your liking.
Last-Modified: 2007-03-07 19:38:50