2.x kernel exploits and workarounds

[MartinEve]

There are now 2 working local root exploits in the wild for all variants of 2.x Linux Kernel, including all those shipped with Ubuntu.

See http://www.kernelpodcast.org/2009/08/14/20090813-linux-kernel-podcast/ for more.

While kernel 2.6.31-rc6 contains the fix, are there any workarounds or measures that can be taken by individuals users in the meantime to mitigate against such an attack?

Martin

[sasho_zl]

Yes there are - just be careful to who you are giving local access to your machine and use strong passwords. :)

[MartinEve]

Yes there are - just be careful to who you are giving local access to your machine and use strong passwords. :)

I kind of anticipated this response, but it's not entirely helpful; it seems to me that these steps are entirely obvious. However, these exploits turn an exploit against any running network daemon into a full-blown root exploit :(

Even if you have the best passwords going, any daemon that turns out to have a vulnerability compromises the entire box.

[sasho_zl]

Ubuntu uses the Novell's "AppArmor". It is enabled by default but you can download additional profiles from synaptic and then enforce them. That will take care of most of those daemons. Also those exploits are from the type of "null pointer" exploits which are very easy to patch. I won't be surprised if the updates are ready for deployment in a day or so.

[movieman]

Even if you have the best passwords going, any daemon that turns out to have a vulnerability compromises the entire box.

Not with proper Apparmor or SELinux protection.

[moron]

Howdy. A kernel updated rolled on in today but on KDE4 / Kubuntu at least, the GUI update-manager is pretty broken still and does not offer any of the extra information about what has changed and such (no release notes, etc.). I have taken a look around the security mailing list and see no references to this so am asking here.

A major kernel related vulnerability was discovered a short while back for which exploits are already out in the wild:

http://www.securityfocus.com/bid/36038

The fix is here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e694958388c50148389b0e9b9e9e894 5cf0f1b98

It looks like Debian has issued patches but it is unclear whether these have made it into Ubuntu yet.

A uname -a after today's update gives me:

2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29

That is well before the first advisory was issued for the sendpage bug.

That still looks like it is in the vulnerable version range. Is this typo and the change has actually been backported (and just the kernel date not changed) or is the vulnerable version still being pushed out? Is the only option at this point to download the kernel sources and edit them by hand?

I was definitely surprised not to see anything about this on the Ubuntu security pages considering the potential severity of the issue.

Cheers

[fhanthomet]

The exploit hosted here http://grsecurity.net/~spender/wunderbar_emporium.tgz (http://grsecurity.net/%7Espender/wunderbar_emporium.tgz) works on my 8.10 desktop installation. I should note that I am of course fully patched and thus running the 2.6.27-14-generic kernel.

So the answer to your question I guess is no the exploit is not patched yet in my repositories.

A quick fix to close up some of the vulnerability is setting the kernel parameter vm.mmap_min_addr to something higher than the 0 it is by default set to.
WARNING: Whether this breaks Wine og other programs relying on the unsafe value of 0 I cannot say. Also I cannot promise that there are not other ways to reset mmap_min_addr or get around it. But at least it closes the exploit code I link to (which tries a few neat tricks to get root).

ADDED: I tried the exploit on a fully updated 9.04 desktop installation and here the parameter mentioned above is already set to a saner value, so the exploit in the link does not work. Ahhh... to be updated and safe(r).

[fhanthomet]

Not everyone is skilled enough to properly configure AppArmor. And almost no one is skilled enough to configure SELinux. :)

So I think it would be nice to disseminate information instead of just hand-waving. Yes I am aware that the exploits we discuss require code to be run locally (so you need a remote exploit or carelessness in combination to do damage), but again some people hand-wave remote exploits saying 'Oh it only grants the attacker local user access'. IMHO we should take every broken layer of security seriously even if it is believed to be covered up by another layer.

For the original poster I found a (somewhat mitigating) work-around the currently unpatched state of updatedness (for Ubuntu 8.10). See my posting here:
http://ubuntuforums.org/showthread.php?t=1243721

NOTE: As the thread now shows I did not find the 9.04 default installation to be vulnerable. But my fully patched 8.10 is, so if you are running behind (like me) and feeling paranoid about local privilege escalation, go set the kernel parameter mmap_min_addr to something higher than 0.

[movieman]

I tried the exploit on a fully updated 9.04 desktop installation and here the parameter mentioned above is already set to a saner value, so the exploit in the link does not work.

Not if you have Wine installed, in which case it gets forced to zero.

[movieman]

IMHO we should take every broken layer of security seriously even if it is believed to be covered up by another layer.

But, equally, you shouldn't panic and disconnect your computer from the Internet because of something which can only be exploited by a local user unless they find a third level of bug (on top of poor system configuration and kernel bugs) which allows them to run the code on your system remotely.

[Agent ME]

For the original poster I found a (somewhat mitigating) work-around the currently unpatched state of updatedness (for Ubuntu 8.10). See my posting here:
http://ubuntuforums.org/showthread.php?t=1243721

NOTE: As the thread now shows I did not find the 9.04 default installation to be vulnerable. But my fully patched 8.10 is, so if you are running behind (like me) and feeling paranoid about local privilege escalation, go set the kernel parameter mmap_min_addr to something higher than 0.
Just tested, and my fully updated 9.04 system is vulnerable. Is this unexpected? (Never have messed with pulseaudio or the kernels myself.)

[rookcifer]

Not with proper Apparmor or SELinux protection.

MAC's are not magic bullets either. There have been at least a few remote exploits that render SELinux and AppArmor completely worthless (i.e. turn them off). Brad Spengler (of GrSecurity) found one recently that did just that

[movieman]

MAC's are not magic bullets either. There have been at least a few remote exploits that render SELinux and AppArmor completely worthless (i.e. turn them off). Brad Spengler (of GrSecurity) found one recently that did just that

I'd be interested to see a cite for that, since Google can't find anything.

The only thing I'm aware of that Spengler has done recently was to demonstrate how to exploit this very null pointer bug we're currently talking about.

[MartinEve]

I haven't seen a remote exploit that disables SELinux; Spengler stated that SELinux makes the NULL pointer exploit (under discussion) easier to exploit (locally): http://news.cnet.com/8301-1009_3-10291022-83.html

However, without wanting to offend anyone, I really don't buy into the philosophy of, there's a bug/exploit, but nobody can get to the stage where it's exploitable. This defeats the whole point of defense-in-depth. This is the same stance taken by many kernel developers who decry every bug as being "only" a DoS (this one included)

The update is to 2.6.28.15.20 and the fix went into 2.6.31. I'd hope it would be backported, but probably not. Will test later.

Martin

[cariboo907]

Updated kerenls were released today (http://www.ubuntu.com/usn/usn-819-1), Aug. 19/09. Go do the update.

[rookcifer]

I'd be interested to see a cite for that, since Google can't find anything.

Sure thing. Here is a video Spengler posted showing his most recent exploit that disables SELinux: http://www.youtube.com/watch?v=UdkpJ13e6Z0

Here is a news article about it: http://www.theregister.co.uk/2009/07/17/linux_kernel_exploit/

Quote:

The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.

And then there is this exploit which was discovered by "sgrakkyu" and detailed on his blog here. (http://kernelbof.blogspot.com/) He shows how it can bypass SeLinux. He also points out how the kernel developers often ignore (or are ignorant of) the severity of so-called "denial of service" vulnerabilities. The exploit he demonstrates here was labeled as a mere DOS by the kernel developers, when in fact it was really a remote root exploit that could bypass LSM and SELinux!

[movieman]

Sure thing. Here is a video Spengler posted showing his most recent exploit that disables SELinux: http://www.youtube.com/watch?v=UdkpJ13e6Z0

But that's a local exploit, and I believe it's the same one we're discussing here.

And then there is this exploit which was discovered by "sgrakkyu" and detailed on his blog here. (http://kernelbof.blogspot.com/) He shows how it can bypass SeLinux. He also points out how the kernel developers often ignore (or are ignorant of) the severity of so-called "denial of service" vulnerabilities. The exploit he demonstrates here was labeled as a mere DOS by the kernel developers, when in fact it was really a remote root exploit that could bypass LSM and SELinux!

That seems more interesting, but I do wonder why you'd worry about disabling SELinux if you have a remote kernel exploit which apparently allowed completely control of the PC; the only benefit I can see of disabling SELinux then would be to use yet another exploit in userland code (e.g. the web server) which would otherwise be blocked by SELinux. And why bother?

I'd be far more worried if there was a remote exploit which could disable SELinux _without_ relying on remotely exploitable kernel bugs which give you control over the OS anyway. In the latter case you have far more important things to worry about.

[bek99]

Updated kerenls were released today (http://www.ubuntu.com/usn/usn-819-1), Aug. 19/09. Go do the update.

I didn't see amd64 on the list at all under 8.04 usn-819-1 bulletin. Is that one still being worked on or is that kernel unaffected? (I would think it would be)

thanks!

[cariboo907]

The generic kernel is used for both 32-bit and 64-bit, they are combined into one download, during installation your cpu is detected and the right kernel installed.

[bek99]

The generic kernel is used for both 32-bit and 64-bit, they are combined into one download, during installation your cpu is detected and the right kernel installed.

It would show up via apt-get though wouldn't it (assuming you all of the repositories,etc)? I haven't seen anything come across to update the kernel at all at least on 64bit systems. generic or otherwise.

-b

[cariboo907]

I just updated my laptop running Jaunty for the first time in a month and a half :(. I got the proper new kernel.

Linux mcleese 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

[bek99]

I just updated my laptop running Jaunty for the first time in a month and a half :(. I got the proper new kernel.

Linux mcleese 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

Must not be in the stream for 8.04 yet then.

ii linux-image-2.6.24-23-server 2.6.24-23.52 Linux kernel image for version 2.6.24 on x86
ii linux-image-server 2.6.24.23.25 Linux kernel image on Server Equipment.
ii linux-server 2.6.24.23.25 Complete Linux kernel on Server Equipment.
ii linux-ubuntu-modules-2.6.24-23-server 2.6.24-23.37 Ubuntu supplied Linux modules for version 2.

[kevdog]

What if your not running Jaunty? Are security patches supposed to be released to older distro's for a given lifespan?

[movieman]

What if your not running Jaunty? Are security patches supposed to be released to older distro's for a given lifespan?

See the previously posted URL:

http://www.ubuntu.com/usn/usn-819-1

[dk06]

http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html

Thursday, August 13, 2009

Linux NULL pointer dereference due to incorrect proto_ops initializations (CVE-2009-2692) (http://blog.cr0.org/2009/08/linux-null-pointer-dereference-due-to.html)

EDIT2: Here (https://bugzilla.redhat.com/show_bug.cgi?id=516949#c10) is RedHat's official mitigation recommendation
EDIT3: Brad Spengler (http://www.grsecurity.net/) also wrote an exploit for this and published it (http://grsecurity.net/%7Espender/wunderbar_emporium.tgz). The bug triggering is based on our exploit which leaked to Brad though the private vendor-sec mailing list. He implements the personality trick (http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html) Tavis and I published in June to bypass mmap_min_addr and also makes use of a feature that allows any unconfined user to gain the right to map at address zero (http://danwalsh.livejournal.com/30084.html) in Redhat's default SELinux policy. He wrote a reliable shellcode for this one that should work pretty much anywhere on x86 and x86_64 machines.
EDIT4: if you use Debian or Ubuntu on your machine, I have specifically updated the kernelsec Debian/Ubuntu GrSecurity packages (http://kernelsec.cr0.org/) to protect against this bug and others.


http://kernelsec.cr0.org/

[kevdog]

See the previously posted URL:

http://www.ubuntu.com/usn/usn-819-1

Thanks -- that update was picked up automatically and installed by the updater - amazing when things work like they are supposed too

[bodhi.zazen]

There are now 2 working local root exploits in the wild for all variants of 2.x Linux Kernel, including all those shipped with Ubuntu.

See http://www.kernelpodcast.org/2009/08/14/20090813-linux-kernel-podcast/ for more.

While kernel 2.6.31-rc6 contains the fix, are there any workarounds or measures that can be taken by individuals users in the meantime to mitigate against such an attack?

Martin

What makes you think you were vulnerable ?

From http://www.ubuntu.com/usn/usn-819-1

A local attacker could exploit this to gain root privileges. By default, Ubuntu 8.04 and later with a non-zero /proc/sys/vm/mmap_min_addr setting were not vulnerable.

So first a cracker would need local access and second that report states Ubuntu 8.04 and later were not vulnerable.

In the first instance, if a cracker has local access, you are pwned already.

In the second instance, did you change the settings or are you running an earlier version of Ubuntu ?

[movieman]

So first a cracker would need local access and second that report states Ubuntu 8.04 and later were not vulnerable.

By default.

If you installed Wine, then you were 100% vulnerable, because it changes the default behaviour to allow mapping page zero.

[bek99]

What makes you think you were vulnerable ?

From http://www.ubuntu.com/usn/usn-819-1



So first a cracker would need local access and second that report states Ubuntu 8.04 and later were not vulnerable.

In the first instance, if a cracker has local access, you are pwned already.

In the second instance, did you change the settings or are you running an earlier version of Ubuntu ?


Local access = someone managing to exploit another service that doesn't yield root, but access to the machine. (whether it's poor code and a malicious script on a web server or some other service being exploited)

No, didn't mess with settings and no wine is installed on production equipment.. Just want to keep things current should that setting get tampered with by someone or something else, I'd rather not leave the hole to be potentially exposed.

[bodhi.zazen]

Local access = someone managing to exploit another service that doesn't yield root, but access to the machine. (whether it's poor code and a malicious script on a web server or some other service being exploited)

As I said before, if I have local (physical) access, I have root access. With physical access this is trivial and there is no need to work through such complex algorithms such as kernel or service exploits or root kits or anything like that. Why do you think they keep servers in locked rooms ?

[MartinEve]

As I said before, if I have local (physical) access

Woah, stop right there.

Local access does NOT mean physical access.

Local access, in the context of exploits and cracking, means having a shell/user account on the box.

[bodhi.zazen]

Woah, stop right there.

Local access does NOT mean physical access.

Local access, in the context of exploits and cracking, means having a shell/user account on the box.

Well if that is what you mean by "local access" my mistake. It then depends on what kind of access we are talking about, a regular authorized user or a cracker who has unauthorized access.

I am used to seeing what your are terming "local access" as remote access (ie ssh or similar) and cracking as well a cracked account.

Shell access is potentially very dangerous and there are many ways shell access can be leveraged. IMO this is only bad and now we are talking SELinux and Apparmor.

Edit: I would not be so cavalier as to allow unrestricted shell access. There are reasons why one asks users to authenticate to log into their systems and shell access certainly can be leveraged.

[MartinEve]

Yeah, there seems to have been some confusion of terminology :)

If you have physical access you could just mount the filesystem from a LiveCD. Game over!

However, in the lingo I am familiar with:

A remote exploit is one in which the cracker has no access to the box. The exploit breaks a remote service (network daemon) in order to provide local access.

Conversely, "local exploits" are those in which the code is executed locally (ie. under the privileges of a local user). This "local" execution can be started by a service (such as SSH), but essentially you are (from the viewpoint of the compromised box) running code there (local) rather than on your machine (remote).

A cracker could obtain local access by using a remote exploit and then use a local exploit to escalate his privileges.

While there is a great capacity for shell access to be badly configured, the very purpose of user privilege roles is to prevent users from performing dangerous operations. A local exploit that gives root is circumventing this measure.

Consider, for example, the many many hosting providers who offer shared space with ssh access. This exploit would allow root to the box and access to all other websites on the system.

[bodhi.zazen]

I believe we are in agreement. Thank you for taking the time to clarify.