# Yet another kernel root exploit

## BitJam

This one only affects 64-bit kernels that can run 32-bit apps.

I applied this patch that I found linked to in this article.  It did not prevent my  2.6.32-gentoo-r3 from running.  I ended up applying the patch manually.

Slashdot is reporting that there is already an exploit in the wild called Ac1db1tch3z.  The Ksplice tool did not work on my machine.   I got: "!!! Error in setting cred shellcodes".  It's possible the Slashdot article is a Slashvertisment for Ksplice.

I'm wondering if there is an easy way to always run a browser inside of a chroot jail.  ISTM that we might even want to have something like this enabled by default.

----------

## Herring42

Fixed in latest kernels:

Changelog

```

16 Sep 2010; Mike Pagano <mpagano@gentoo.org>

9    +gentoo-sources-2.6.34-r10.ebuild, +gentoo-sources-2.6.35-r7.ebuild:

10    Fix for exploit: IA32 Syscall Entry Point Privilege Escalation

11    (CVE-2010-3301) 

```

----------

## Hu

 *BitJam wrote:*   

> I'm wondering if there is an easy way to always run a browser inside of a chroot jail.  ISTM that we might even want to have something like this enabled by default.

 Although such a setup could be desirable in general, it would do you no good in this case.  Processes in a chroot jail can still make system calls, and this bug affected the validation of system call arguments.  Anyone who can run code of their choosing can exploit this, whether or not they are in a chroot jail.

----------

## BitJam

Yes, but wouldn't it be less likely that they could cause permanent damage by running such code?  I thought that was sort of the point of a chroot jail so that even if someone gains root, they still can't (easily) compromise your system.   Does a chroot jail provide some other benefit besides this?  I thought this was, in theory at least, why a chroot jail was safer than just running as a normal user with limited privileges.

----------

## MotivatedTea

chroot does not prevent "root" from doing whatever he wants. chroot was not really designed to be the kind of security mechanism many people think it is, although it can help with security. See this wikipedia article for a list of the things it was designed for. This page describes best practices for using chroot, including an overview of how root would go about breaking out of a chroot. chroot can be fairly effective in limiting normal user accounts, but if a user can get root access through a privilege escalation exploit (like this security hole), chroot won't help.

----------

## krinn

chroot jail were just done to prevent a user with root privileges (deamon, some power users, or even a distracted root user) that could run root to do bad things by mistake (not to jail someone that cannot escape the jail, but someone that don't wish to escape it), else on a well build system, you don't need to chroot your users as they should already be limited

it's not a security feature, more a buoy, as target audience can escape it, but shouldn't wish to do that

and someone trying tricks on your system to get root privilege isn't really in that category

on another note, for a server i prefer 32bits as code is years old, know, and test.

if i made a 64bits server (for what? running mathlab or converting video faster?), i woudn't use 32bits programs at all, who cares to run a 32bits flash on a server, it's not a desktop system.

----------

## Herring42

 *krinn wrote:*   

> 
> 
> on another note, for a server i prefer 32bits as code is years old, know, and test.
> 
> if i made a 64bits server (for what? running mathlab or converting video faster?), i woudn't use 32bits programs at all, who cares to run a 32bits flash on a server, it's not a desktop system.

 

64 Bits is kinda handy for running more than 3GB of RAM...

----------

## Anon-E-moose

 *Herring42 wrote:*   

>  *krinn wrote:*   
> 
> on another note, for a server i prefer 32bits as code is years old, know, and test.
> 
> if i made a 64bits server (for what? running mathlab or converting video faster?), i woudn't use 32bits programs at all, who cares to run a 32bits flash on a server, it's not a desktop system. 
> ...

 

Or for converting videos, or music, etc. I run a multilib system I have no problems running everything from server stuff, to media, to FF w/adobe (64 not 32)

----------

## Hu

If we accept that 32-bit legacy applications have no place on a 64-bit server, then the server can be run with a no-multilib profile and IA32 emulation disabled entirely.  This would reduce space used and available attack surface.

----------

## krinn

That was what i have in mind too Hu. But i like to put more words for nothing & lost the reader.

----------

