WARN: Major kernel vuln: affects 2.6.x + 2.4.x + 2.2.x

I haven't looked over the details yet, but here is the vulnerability.
2.4.24 has the fix.

//moderator.update: for 2.6 series 2.6.1-rc2 is out (thnx jtshaw)

//nu thread for mgmnt purposes. TIA Chort for alerting.

Update:

[RHSA-2003:417-01] Updated kernel resolves security vulnerability

Date: Mon, 5 Jan 2004 07:54 -0500

Synopsis: Updated kernel resolves security vulnerability
Advisory ID: RHSA-2003:417-01
Issue date: 2004-01-05
Updated on: 2004-01-05
Product: Red Hat Linux
CVE Names: CAN-2003-0984 CAN-2003-0985

1. Topic:
Updated kernel packages are now available that fix a security
vulnerability which may allow local users to gain root privileges.

2. (...)

3. Problem description:
The Linux kernel handles the basic functions of the operating system.

Paul Starzetz discovered a flaw in bounds checking in mremap() in the Linux
kernel versions 2.4.23 and previous which may allow a local attacker to
gain root privileges. No exploit is currently available; however, it is
believed that this issue is exploitable (although not trivially.) The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0985 to this issue.

All users are advised to upgrade to these errata packages, which contain a
backported security patch that corrects this issue.

Red Hat would like to thank Paul Starzetz from ISEC for disclosing this
issue as well as Andrea Arcangeli and Solar Designer for working on the patch.

These packages also contain a fix for a minor information leak in the real
time clock (rtc) routines. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2003-0984 to this issue.

(...)

Well I just had the time to read the published vulnerability. In particular please note:

Version: 2.2, 2.4 and 2.6 series

So in addition to 2.4.x, 2.2.x and 2.6.x are also vulnerable! I apologize for any false sense of security I might have conveyed to users of those kernels. If a mod would be so kind as to revise the subject title to reflect this, I would appreciate it.

Also, apparently, this vulnerability can be used to gain a root shell from the following:

Impact: ======= Since no special privileges are required to use the mremap(2) system call any process may misuse its unexpected behavior to disrupt the kernel memory management subsystem. Proper exploitation of this vulnerability may lead to local privilege escalation including execution of arbitrary code with kernel level access. Proof-of-concept exploit code has been created and successfully tested giving UID 0 shell on vulnerable systems. The exploitability of the discovered vulnerability is possible, although not a trivial one. We have identified at least two different attack vectors for the 2.4 kernel series. All users are encouraged to patch all vulnerable systems as soon as appropriate vendor patches are released.

So this is similar do the do_brk() vuln in that local users with no privileges can escalate to root. The same precautions should be taken of changing passwords, regenerating public/private keypairs, changing passphrases, etc. Also consider locking user accounts until you can verify that the user has changed their authentication information.

//I asked Jeremy to change the title, should be done RSN.

Excellent, thanks!

Also, since that site is likely to get Slashdotted (that's where I found it) here's the full text. Please consider my above link as the authoritative source, since the description may change or be appened.

Synopsis: Linux kernel do_mremap local privilege escalation vulnerability Product: Linux kernel Version: 2.2, 2.4 and 2.6 series Vendor: http://www.kernel.org/ URL: http://isec.pl/vulnerabilities/isec-0013-mremap.txt CVE: http://cve.mitre.org/cgi-bin/cvename...=CAN-2003-0985 Author: Paul Starzetz <ihaquer@isec.pl>, Wojciech Purczynski <cliph@isec.pl> Date: January 5, 2004 Issue: ====== A critical security vulnerability has been found in the Linux kernel memory management code in mremap(2) system call due to incorrect bound checks. Details: ======== The mremap system call provides functionality of resizing (shrinking or growing) as well as moving across process's addressable space of existing virtual memory areas (VMAs) or any of its parts. A typical VMA covers at least one memory page (which is exactly 4kB on the i386 architecture). An incorrect bound check discovered inside the do_mremap() kernel code performing remapping of a virtual memory area may lead to creation of a virtual memory area of 0 bytes length. The problem bases on the general mremap flaw that remapping of 2 pages from inside a VMA creates a memory hole of only one page in length but an additional VMA of two pages. In the case of a zero sized remapping request no VMA hole is created but an additional VMA descriptor of 0 bytes in length is created. Such a malicious virtual memory area may disrupt the operation of other parts of the kernel memory management subroutines finally leading to unexpected behavior. A typical process's memory layout showing invalid VMA created with mremap system call: 08048000-0804c000 r-xp 00000000 03:05 959142 /tmp/test 0804c000-0804d000 rw-p 00003000 03:05 959142 /tmp/test 0804d000-0804e000 rwxp 00000000 00:00 0 40000000-40014000 r-xp 00000000 03:05 1544523 /lib/ld-2.3.2.so 40014000-40015000 rw-p 00013000 03:05 1544523 /lib/ld-2.3.2.so 40015000-40016000 rw-p 00000000 00:00 0 4002c000-40158000 r-xp 00000000 03:05 1544529 /lib/libc.so.6 40158000-4015d000 rw-p 0012b000 03:05 1544529 /lib/libc.so.6 4015d000-4015f000 rw-p 00000000 00:00 0[*] 60000000-60000000 rwxp 00000000 00:00 0 bfffe000-c0000000 rwxp fffff000 00:00 0 The broken VMA in the above example has been marked with a[*]. Impact: ======= Since no special privileges are required to use the mremap(2) system call any process may misuse its unexpected behavior to disrupt the kernel memory management subsystem. Proper exploitation of this vulnerability may lead to local privilege escalation including execution of arbitrary code with kernel level access. Proof-of-concept exploit code has been created and successfully tested giving UID 0 shell on vulnerable systems. The exploitability of the discovered vulnerability is possible, although not a trivial one. We have identified at least two different attack vectors for the 2.4 kernel series. All users are encouraged to patch all vulnerable systems as soon as appropriate vendor patches are released. Credits: ======== Paul Starzetz <ihaquer@isec.pl> has identified the vulnerability and performed further research. Disclaimer: =========== This document and all the information it contains are provided "as is", for educational purposes only, without warranty of any kind, whether express or implied. The authors reserve the right not to be responsible for the topicality, correctness, completeness or quality of the information provided in this document. Liability claims regarding damage caused by the use of any information provided, including any kind of information which is incomplete or incorrect, will therefore be rejected.

Kernel.org, released: 2004-01-05 13:55 UTC

From the changelog:

- 2.4.24-rc1 was released as 2.4.24 with no changes.
Summary of changes from v2.4.23 to v2.4.24-rc1
============================================
(...)
<marcelo.tosatti:cyclades.com>:
o Andrea Arcangeli: malicious users of mremap() syscall can gain priviledges
(...)


//POC for x68 is on the Bugtraq/FD mailinglist...

So...as of right now there doesn't appear to be a fix for the 2.6.0 kernel?


Thanks,
Whitehat

From the LKML:

> Why isn't there any security update to 2.6.0/2.6.1-rc1 out yet, then?

Because nobody actually contacted me about the problem and I read about it
on linux-kernel like everybody else? Because I just got up and created the
patch? And because nobody has an exploit yet, and one may be hard or
impossible to create? And because people who care about these things tend
to not update to x.0 kernels anyway?

> But I think there's corporations who use 2.6.0 and don't read the lkml.

They'll get a 2.6.1 soonish. The patch is in the current BK tree, will be
in -rc2, and will be in 2.6.1. Let's just make sure we don't screw up the
release due to being too much in a hurry either..

Linus

Wow. That's not exactly encouraging for 2.6.x users. "... people who care about these things tend not to update to x.0 ..." (emphasis added). What, people who care about not having locally exploitable kernels? Given that several Linux distributions have 2.6 as standard and some professional sites are sure to be using them, I would hope for a little more sense of urgency ("they'll get a 2.6.1 soonish") in issuing a patch.

Oh, and this part: "And because nobody has an exploit yet, and one may be hard or
impossible to create?" would seem a little bit silly, given that a POC has been posted on Bugtraq. They're sure not doing anything to assure corporations that Linux is "enterprise-friendly", then again maybe that's what enterprises expect after years of Sun and Microsoft.

Given that several Linux distributions have 2.6 as standard and some professional sites are sure to be using them, I would hope for a little more sense of urgency ("they'll get a 2.6.1 soonish") in issuing a patch.
I agree providing a patch should be prio one. BTW, which current distro releases default to 2.6.x instead of 2.4.x?

I was lead to believe that Mandrake does. Perhaps I was mislead?

Mandy's 9.2 defaults to 2.4.x.
Prerelease snapshots (Cooker) have 2.6.x, yeah.

Originally posted by unSpawn From the LKML: > Why isn't there any security update to 2.6.0/2.6.1-rc1 out yet, then? Because nobody actually contacted me about the problem and I read about it on linux-kernel like everybody else? Because I just got up and created the patch? And because nobody has an exploit yet, and one may be hard or impossible to create? And because people who care about these things tend to not update to x.0 kernels anyway? > But I think there's corporations who use 2.6.0 and don't read the lkml. They'll get a 2.6.1 soonish. The patch is in the current BK tree, will be in -rc2, and will be in 2.6.1. Let's just make sure we don't screw up the release due to being too much in a hurry either.. Linus

Hmmm.. maybe that is one reason I left my publicly accessible computers I run myself on the 2.4.x series.
I know some corporations and such always jump to the latest versions of anything, etc but this is one reason I tend to wait, even if it is deemed as stable, doesn't always deem it as secure since its so new.

I'll most likely wait later down the kernel tree and releases before making updating my own personal servers compiled with the latest kernel.

But yeah, my "exposed" machines to the world have been patched and updated at this time. Thanks for the heads up or I probably wouldn't have noticed til I stumbled upon it at one of the many linux sites I seem to not been visiting lately, instead just reading the SCO crapsuit at groklaw.net.

Ok, enough rambling....

Cheers

SuSE users, patches are available thru online update. you may (i had to) update your gpg signatures first. if yast barfs, install this package first, then run online update.

We all know that technically speaking 2.6 should be stable.... However, you have to be somewhat realistic here. Most people never tried a 2.5 kernel or a 2.6 test kernel. Now that 2.6 is out, and there are a ton of people trying it because it is in the stable tree, there will be tons of bugs and such reported and fixed. We will probably be on 2.6.5 or higher by May knowing how things went with 2.4. Then things will start to settle down. It is a fact of life unfortunetly because not enough people test things on the development kernels. The way linux development works you would have to be on crack to include a kernel that is relatively untested like 2.6.0 in your distribution as the default. I agree Linus should get a patch out asap, but the most important thing for enterprise linux was for the 2.4 kernel to get fixed.