WARN: Major kernel vuln: affects 2.6.x + 2.4.x + 2.2.x
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Original Poster
Rep:
Well I just had the time to read the published vulnerability. In particular please note:
Quote:
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:
Quote:
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.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Original Poster
Rep:
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.
Quote:
Synopsis: Linux kernel do_mremap local privilege escalation vulnerability
Product: Linux kernel
Version: 2.2, 2.4 and 2.6 series
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:
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.
- 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
(...)
> 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..
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Original Poster
Rep:
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?
> 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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.