LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 01-05-2004, 01:02 PM   #1
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
WARN: Another 2.4.x kernel vuln


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)

Last edited by unSpawn; 01-06-2004 at 02:38 PM.
 
Old 01-05-2004, 01:24 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

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

//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.

(...)

Last edited by unSpawn; 01-05-2004 at 01:58 PM.
 
Old 01-05-2004, 01:55 PM   #3
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Original Poster
Rep: Reputation: 69
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.
 
Old 01-05-2004, 02:09 PM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

Rep: Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745
//I asked Jeremy to change the title, should be done RSN.
 
Old 01-05-2004, 02:12 PM   #5
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Original Poster
Rep: Reputation: 69
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

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.
 
Old 01-05-2004, 03:08 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

Rep: Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745
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...

Last edited by unSpawn; 01-05-2004 at 03:15 PM.
 
Old 01-05-2004, 05:20 PM   #7
Whitehat
Senior Member
 
Registered: Feb 2003
Location: The Cold North
Distribution: SuSE 9.1
Posts: 1,289

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


Thanks,
Whitehat
 
Old 01-05-2004, 05:50 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

Rep: Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745
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
 
Old 01-05-2004, 06:04 PM   #9
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Original Poster
Rep: Reputation: 69
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.

Last edited by chort; 01-05-2004 at 06:06 PM.
 
Old 01-05-2004, 06:41 PM   #10
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

Rep: Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745
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?
 
Old 01-05-2004, 06:50 PM   #11
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Original Poster
Rep: Reputation: 69
I was lead to believe that Mandrake does. Perhaps I was mislead?
 
Old 01-05-2004, 06:57 PM   #12
unSpawn
Moderator
 
Registered: May 2001
Posts: 26,994
Blog Entries: 54

Rep: Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745Reputation: 2745
Mandy's 9.2 defaults to 2.4.x.
Prerelease snapshots (Cooker) have 2.6.x, yeah.
 
Old 01-05-2004, 07:26 PM   #13
trickykid
Guru
 
Registered: Jan 2001
Posts: 24,133

Rep: Reputation: 197Reputation: 197
Quote:
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
 
Old 01-05-2004, 07:40 PM   #14
rshaw
Senior Member
 
Registered: Apr 2001
Location: Perry, Iowa
Distribution: Mepis , Debian
Posts: 2,694

Rep: Reputation: 45
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.
 
Old 01-05-2004, 11:01 PM   #15
jtshaw
Senior Member
 
Registered: Nov 2000
Location: Seattle, WA USA
Distribution: Ubuntu @ Home, RHEL @ Work
Posts: 3,892
Blog Entries: 1

Rep: Reputation: 66
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Remote Kernel Vulnerability affects 2.6.9 TruckStuff Linux - Security 1 12-16-2004 09:21 AM
Kernel Crash-Exploit affects 2.4.2x and 2.6.x kernels on x86 and x86_64 unSpawn Linux - Security 8 11-24-2004 01:29 PM
WARN: Kernel vuln: MCAST_MSFILTER (2.4.22/2.6.1) unSpawn Linux - Security 5 05-04-2004 12:41 PM
WARN: Kernel 2.6/Samba privilage escalation vuln chort Linux - Security 0 02-15-2004 04:27 AM
WARN: kernel local vuln.: upgrade to 2.4.23 or 2.6.0-test6 unSpawn Linux - Security 14 12-27-2003 12:37 PM


All times are GMT -5. The time now is 11:50 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration