WARN: kernel local vuln.: upgrade to 2.4.23 or 2.6.0-test6

From http://cve.mitre.org/cgi-bin/cvename...=CAN-2003-0961 :
a "flaw in bounds checking" in the do_brk function for Linux kernel 2.4.22 and earlier allows local users to gain root privileges.

From http://isec.pl/vulnerabilities/isec-0012-do_brk.txt :
Successful exploitation of do_brk() leads to full compromise of vulnerable system, including gaining full uid 0 privileges, possibility of kernel code and data structures modification as well as kernel-level (ring0) code execution. Tested and successfully exploited kernel versions include:
2.4.20-18.9 as shipped with RedHat 9.0, 2.4.22 (vanila), 2.4.22 with grsecurity patch
There is no known reliable workaround for this vulnerability except. We recommend upgrading to the most recent kernel version (so far the 2.4.23 kernel) on all vulnerable systems.

Also see: Debian Security Advisory DSA-403-1, http://www.debian.org/security/


So watch your vendors security bulletins for vendor-specific kernel releases or upgrade to kernel 2.4.23. Kudos to Chort who warned first here: http://www.linuxquestions.org/questi...hreadid=121868

In case anybody is interested: here is a more detailed description on what happened - i found it quite interesting to read:
http://kerneltrap.org/node/view/1717

Slackware security advisory and kernel upgrade instructions

What I don't get is if we are supposed to upgrade the kernel past the 2.4.23 build, why is RedHat releasing new kernel rpms based on the 2.4.20-24 kernel? Should I go with the RedHat RPMs (all my RH machines are production machines) or compile the 2.4.23 kernel from http://www.kernel.org ?

I assume redhat has fixed the security problem in their 2.4.20 based kernel.
I'd use the redhat kernel.

Originally posted by Pcghost What I don't get is if we are supposed to upgrade the kernel past the 2.4.23 build, why is RedHat releasing new kernel rpms based on the 2.4.20-24 kernel? Should I go with the RedHat RPMs (all my RH machines are production machines) or compile the 2.4.23 kernel from http://www.kernel.org ?

I just want to add, that the fix for this problem is really a 2-liner:

--- 1.31/mm/mmap.c      Fri Sep 12 06:44:06 2003
+++ 1.32/mm/mmap.c      Thu Oct  2 01:18:19 2003
@@ -1041,6 +1041,9 @@
        if (!len)
                return addr;
 
+       if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+               return -EINVAL;
+
        /*
         * mlock MCL_FUTURE?
         */

So you could even patch 2.4.18 if you want to

Gentoo's server got compromised because of the same vulnerability. I assume there will be a target search in the next time. Secure your boxes, configure AIDE & more...

Geez - why didn't they upgrade the kernel already? They had the time...
I just like Gentoo but this kinda stinks... imho....

It may have already been compromised and they just now discovered it. You have to think that the same people who compromised Debian were running wild all over the place since no one knew about it.

I just hope you're right - but shouldn't one discover it more or less instantly? If any file gets altered, you should get a warning - may be the Gentoo servers didn't have such a tight security than the Debian ones...

Debian used AIDE on 2 servers for monitoring filesystem changes. Well regarding details you may take a look at http://isec.pl/papers/linux_kernel_do_brk.pdf, like outlined in VulnWatch.

config can you explain this to me further, thanks!

--- 1.31/mm/mmap.c Fri Sep 12 06:44:06 2003
+++ 1.32/mm/mmap.c Thu Oct 2 01:18:19 2003
@@ -1041,6 +1041,9 @@
if (!len)
return addr;

+ if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+ return -EINVAL;
+
/*
* mlock MCL_FUTURE?
*/

It's a diff patch for the kernel memory management code.

Originally posted by sopiaz57 config can you explain this to me further, thanks!

--- 1.31/mm/mmap.c Fri Sep 12 06:44:06 2003
+++ 1.32/mm/mmap.c Thu Oct 2 01:18:19 2003


This tells which file gets patched and the new version number etc.

@@ -1041,6 +1041,9 @@
        if (!len)
                return addr;

This is really only for locating the place where the new code is supposed to go

+       if ((addr + len) > TASK_SIZE || (addr + len) < addr)
+               return -EINVAL;
+

Now these are the actual changes - the '+' in front means, that these lines are added, a '-' is used, if you want to remove some code within a patch. You see, that this code checks if addr+len isn't larger than TASK_SIZE or smaller than addr. Without this check, the kernel would be vulnerable.

/*
         * mlock MCL_FUTURE?
         *

Don't know what this is good for - may be to make locating the place to insert the code even easier. I don't know - i'm not an expert

Hope this clears things up

Originally posted by Config /* * mlock MCL_FUTURE? * Don't know what this is good for - may be to make locating the place to insert the code even easier. I don't know - i'm not an expert Hope this clears things up

It's basically there as a failsafe in case other lines have been inserted above those since the diff was made. So, if the patch program can't apply the diff at the right line numbers, it looks for a place which fits with the 'context' lines given.

Back on topic, the 2.4.20-gentoo-r9 kernel has fixes this. (gentoo-sources-2.4.20-r9 package)