Root privileges through Linux kernel bug

Interesting read, but there's two things to note:

1) This is a local exploit which means an attacker has to already have broken into the machine by some other means.

2) It has been patched a long time ago. I am not sure why this is news today in August 2010. The kernel versions with the patch are very commonly used today. Ah, I see, these older kernel versions have just been patched within the past few days. Most distros should automatically notify you when security updates are available.

So, if you are using Ubuntu Lucid, you are safe. Any distro with a kernel of 2.6.32+ is safe. Just run

Code:

uname -r

to find out your kernel version.

 

Hi chronomatic,

It is not immediately given/obvious that patches to 2.6.32.19, 2.6.34.4 and 2.6.35.2 which fix this bug are applicable to Ubuntu Lucid which in 10.4.1 is (for me anyway): 2.6.32-24-generic.

Yeah, 2.6.32.19 occurs before 2.5.32-24 (in terms of ordering), but a patch in the source tree in 2.6.32.19 may or may not get inherited into 2.6.32.24 - all of which requires that at the very least perhaps an upgrade of kernel packages is requied - none of which are the aforementioned versions of the kernel.

Using Synaptic Package Manager, searching for linux-source, the latest is:
2.6.32-24.41 for Linux Kernel Source for version 2.6.32 with Ubuntu patches.

So, does this mean that the following is required to acquire the fix: a download of 2.6.32-24.41 sources (hoping the fix is inherited), recompile the kernel, and then install the packages generated?

I use a Live CD environment, and have recompiled kernel souce previously after download which needs to have symbolic debugging turned off else the result is bloated.

I suppose the answer to my question lies in when the kernel patches occurred vs when the new release of Lucid occured (just this week).

-- Tom

 

@ lotuseclat79
As you say it's not immediately apparent. However it does seem that the #41 version is the fix - I just downloaded today. See here... http://www.ubuntu.com/usn/usn-974-1

 

Hi Ocky,

Thanks for the post. CVE-2010-2240 was the related notice.

What that means for me, however, since I use Ubuntu 10.4.1 LTS (Lucid Lynx) in Live CD form (without) installation of Ubuntu is that I must get the latest linux-source packages as mentioned above, patch it, recompile and everytime I boot it install it which is straightforward in order to get the fix. Or, I could craft a special Live CD via chrooting and replace the Linux kernel with the fix instead.

I have an RSS feed to Ubuntu Security Notices and the one you mentioned was just posted yesterday (probably after I had closed down my system for the day).

-- Tom

 

How does that work? AFAIK you can't upgrade the running kernel on ubuntu which doesn't come with something like ksplice.
Anyway I'd create a custom livecd, linux is only one of several packages that need security patches sooner or later. Big hassle to update at each boot. Try remastersys:
http://www.geekconnection.org/remastersys/ubuntu.html
You could for example keep a "master copy" on an HDD and upgrade it whenever there's a relevant patch and recreate the live iso.

Any idea how Apparmor and others stack up wrt these kind of kernel bugs (i.e, assume there's an unrelated remote code execution vuln in a confined app)?

 

Hi katio,

Regarding ksplice - you just install it and it works, even in a Live CD environment. I contacted the authors about a suggested modification that would have allowed a user to select a subset of the total number of security installs that Ksplice makes - but, they declined to make the change - so , I no longer am interested in using it. I wanted to be in control of what gets installed, but Ksplice installs every fix to the kernel - some of which I ventured that I did not need or use at all.

AFAIK, having been in contact with the author of remastersys, it does not work for Live CD environments - i.e. the in-RAM filesystem is not recognized in place of a real installed file system on a hard drive. I may look at the source code for remastersys in the future to figure how to make it do with what I want to do with it - plus, the issue of how much hard drive space you need to be able to do what you mentioned - I only have 4GB - 3GB of which are usable. The kind of fix I have in mind would redirect actions to hard drive instead of in-Ram file system.

Since I use a Live CD environment exclusively, I've created my own environment which is basically nothing more than collecting tarballs of the installed packages and re-installing them via script on every Live CD bootup - no big hassle as it only takes no more than a minute to install them.

I have implemeted a Firefox App Armour configuration file, but after using it decided I did not really want or need it. NoScript suffices for my needs with Firefox - and the author is very quick at incorporating new fixes for users.

-- Tom