Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 37292 - Critical kernel mremp vulnerability
Summary: Critical kernel mremp vulnerability
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: Highest critical (vote)
Assignee: Gentoo Security
URL: http://isec.pl/vulnerabilities/isec-0...
Whiteboard:
Keywords:
: 37293 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-01-05 05:28 UTC by fbusse
Modified: 2011-10-30 22:44 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
mremap-CAN-2003-0985.patch (mremap-CAN-2003-0985.patch,414 bytes, patch)
2004-01-05 09:57 UTC, John Mylchreest (RETIRED)
no flags Details | Diff
Revised mremap patch to solve patching issues (mremap-CAN-2003-0985.patch,414 bytes, patch)
2004-01-05 10:24 UTC, Kerin Millar
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description fbusse 2004-01-05 05:28:32 UTC
This bug exists in kernel 2.2, 2.4 and 2.6 and is exploitable.
RedHat already released fixed kernels with a backported fix.

Here's the original advisory:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-0012-mremap.txt
CVE:       http://cve.mitre.org/cgi-bin/cvename.cgi?name=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 exist
Comment 1 fbusse 2004-01-05 05:28:32 UTC
This bug exists in kernel 2.2, 2.4 and 2.6 and is exploitable.
RedHat already released fixed kernels with a backported fix.

Here's the original advisory:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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-0012-mremap.txt
CVE:       http://cve.mitre.org/cgi-bin/cvename.cgi?name=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 exist­
ing 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 un­
expected 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  ker­
nel memory management subsystem. Proper exploitation of this vulnerabil­
ity may lead to local privilege escalation including execution of  arbi­
trary  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 vec­
tors  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. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH  EXPRESS  PERMISSION  OF
ONE OF THE AUTHORS.


Disclaimer:
===========

This  document and all the information it contains are provided "as is",
for educational purposes only, without warranty of any kind, whether ex­
press 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 in­
complete or incorrect, will therefore be rejected.

- -- 
Paul Starzetz
iSEC Security Research
http://isec.pl/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/+Vj2C+8U3Z5wpu4RApegAKCOkWCWg8Jy/y9S1WtEWxerkkQNbQCgk/X9
8aGjOA7fTT8EynIFw/sgoHU=
=Aw61
-----END PGP SIGNATURE-----
Comment 2 fbusse 2004-01-05 06:32:06 UTC
Kernel 2.4.24 has been released to address this vulnerability:
http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.24
Comment 3 solar (RETIRED) gentoo-dev 2004-01-05 08:51:07 UTC
Anybody have/seen a vendor patch for this?

Or would anybody care to extract the fix out of redhat srpms
http://lists.netsys.com/pipermail/full-disclosure/2004-January/015199.html
Comment 4 Matthias Geerdsen (RETIRED) gentoo-dev 2004-01-05 09:33:32 UTC
Duplicate of BUG #37293 I guess, patch from kernel 2.4.24 given there.
Comment 5 John Mylchreest (RETIRED) gentoo-dev 2004-01-05 09:44:21 UTC
im currently wortking on this now.
please expect glsa/bumps within the next hour or so
Comment 6 John Mylchreest (RETIRED) gentoo-dev 2004-01-05 09:56:54 UTC
the patch applied in 2.4.24 [1] isnt the ideal patch to use.
the patch in [1] doesn an mremap away after the mremap was accepted, instead of just rejecting the request in the first place.
the patch which should be used is attached.
these changes are to be made almost immediately, so hold on to your seats :)

currently, the exploit allows zero sized mremap requests allowing unpriveleged users to access the kernel memory management subsystem.

[1]: http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.4%2Fpatch-2.4.24.bz2;z=16
Comment 7 John Mylchreest (RETIRED) gentoo-dev 2004-01-05 09:57:53 UTC
Created attachment 23194 [details, diff]
mremap-CAN-2003-0985.patch
Comment 8 SpanKY gentoo-dev 2004-01-05 10:04:19 UTC
*** Bug 37293 has been marked as a duplicate of this bug. ***
Comment 9 solar (RETIRED) gentoo-dev 2004-01-05 10:11:29 UTC
Attention all kernel maintainers at gentoo.

If you update a kernel (and your name is not iggy) then please start appending 
exactly what your doing/did to this bug.

-------------------------------------------------------------------------------
<pebenito> so I will use 2.4.24, reverse the mrepap, and use the better fix, for selinux-sources
http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.24
-------------------------------------------------------------------------------

iggy,
When all kernels have been updated please change the Product on this bug from 
to Gentoo GLSA
Comment 10 Kerin Millar 2004-01-05 10:24:40 UTC
Created attachment 23196 [details, diff]
Revised mremap patch to solve patching issues

Apparently solves the matter of rejects for some people.
Comment 11 Andrea Luzzardi 2004-01-05 10:29:52 UTC
hardened-sources-2.4.22-r2 commited
Comment 12 Christian Gut 2004-01-05 10:55:49 UTC
urm, what about the second vulnerability announced by Marcelo and in the ChangeLog for 2.4.24?

"/dev/rtc can leak parts of kernel memory to unpriviledged users"
Comment 13 Chris PeBenito (RETIRED) gentoo-dev 2004-01-05 11:05:02 UTC
selinux-sources-2.4.24 is committed.  I reversed the mremap patch and used the revised mremap patch.
Comment 14 Andrea Luzzardi 2004-01-05 11:06:04 UTC
vanilla-sources-2.4.24 commited. vanilla mremap fix has been kept.
Comment 15 Tim Yamin (RETIRED) gentoo-dev 2004-01-05 11:14:53 UTC
Bug 37317 tracks the RTC issue.
Comment 16 Tim Yamin (RETIRED) gentoo-dev 2004-01-05 13:14:07 UTC
Added development-sources-2.6.1_rc1.ebuild along with the necessary 2.6 patch; removed development-sources-2.6.0_beta7.ebuild...
Comment 17 Tim Yamin (RETIRED) gentoo-dev 2004-01-05 14:23:49 UTC
Added aa-sources-2.4.23-r1.ebuild with the necessary 2.4 patch and the 2.4 RTC patch; removed aa-sources-2.4.23_pre6-r3.ebuild...
Comment 18 Tim Yamin (RETIRED) gentoo-dev 2004-01-05 15:07:49 UTC
Fixed grsec-sources-2.4.23.1.9.13.ebuild and grsec-sources-2.4.23.2.0_rc4.ebuild.
Comment 19 Tim Yamin (RETIRED) gentoo-dev 2004-01-05 16:31:26 UTC
Bumped to and fixed in wolk-sources-4.10_pre7-r2.ebuild and wolk-sources-4.9-r3.ebuild.
Comment 20 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 07:19:06 UTC
Fixed in gentoo-sources-2.4.22-r2.ebuild and gentoo-sources-2.4.20-r10.ebuild.
Comment 21 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 07:51:05 UTC
Fixed in ac-sources-2.4.22-r4.ebuild...
Comment 22 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 08:17:44 UTC
Fixed in alpha-sources-*.ebuild.
Comment 23 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 08:41:51 UTC
Fixed in arm-sources-2.4.19-r2.ebuild.
Comment 24 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 08:56:02 UTC
Fixed in mips-sources-*.ebuild.
Comment 25 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 10:01:13 UTC
Fixed in ck-sources-*.ebuild.
Comment 26 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 13:04:06 UTC
Fixed in ia64-sources-2.4.22-r2.ebuild...
Comment 27 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 14:44:18 UTC
Fixed in openmosix-*.ebuild.
Comment 28 Bill Kenworthy 2004-01-06 15:33:50 UTC
update to gs-sources-2.4.23_pre8-r2 hasnt incremented the version number so it installs over the top of the existing source tree (.e., it says -r2, but the src dir is still linux-2.4.23_pre8-gss).  I think this is the second time this has happened and is very undesirable:

1. you lose the ability to easily see if fixes have been made to a running system
2. any local changes to the tree may be lost
3. confusion

Can a check for this be made at a QA stage to prevent it happening again?

BillK
Comment 29 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 16:03:17 UTC
EXTRAVERSION changed for gs-sources-2.4.23_pre8-r2.ebuild.
Fixed in pac-sources-2.4.23-r2.ebuild.
Fixed in pfeifer-sources-2.4.21.1_pre4-r1.ebuild.
Comment 30 Tim Yamin (RETIRED) gentoo-dev 2004-01-06 16:43:15 UTC
Fixed in rsbac-sources-2.4.20-r1.ebuild.
Comment 31 Wilbur Pan 2004-01-08 19:40:26 UTC
Not to ruffle any feathers, but it's now Thursday night on the East Coast in the US, and there still is not a GLSA regarding this issue?  How come?
Comment 32 Marius Mauch (RETIRED) gentoo-dev 2004-01-08 19:54:44 UTC
check your mail, it went out today around midnight GMT.
Comment 33 Tim Yamin (RETIRED) gentoo-dev 2004-01-09 03:54:08 UTC
All vulnerable kernels have been patched. The GLSA went out at around 23:50UTC yesterday, so this is resolved.