Bug 37292 - Critical kernel mremp vulnerability
|
Bug#:
37292
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: critical
|
Priority: P1
|
|
Resolution: FIXED
|
Assigned To: security@gentoo.org
|
Reported By: fbusse@gmx.de
|
|
Component: Security
|
|
|
URL:
http://isec.pl/vulnerabilities/isec-0012-mremap.txt
|
|
Summary: Critical kernel mremp vulnerability
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2004-01-05 05:28 0000
|
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
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-----
Duplicate of BUG #37293 I guess, patch from kernel 2.4.24 given there.
im currently wortking on this now.
please expect glsa/bumps within the next hour or so
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
*** Bug 37293 has been marked as a duplicate of this bug. ***
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
hardened-sources-2.4.22-r2 commited
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"
selinux-sources-2.4.24 is committed. I reversed the mremap patch and used the
revised mremap patch.
vanilla-sources-2.4.24 commited. vanilla mremap fix has been kept.
Added development-sources-2.6.1_rc1.ebuild along with the necessary 2.6 patch;
removed development-sources-2.6.0_beta7.ebuild...
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...
Fixed grsec-sources-2.4.23.1.9.13.ebuild and
grsec-sources-2.4.23.2.0_rc4.ebuild.
Bumped to and fixed in wolk-sources-4.10_pre7-r2.ebuild and
wolk-sources-4.9-r3.ebuild.
Fixed in gentoo-sources-2.4.22-r2.ebuild and gentoo-sources-2.4.20-r10.ebuild.
Fixed in ac-sources-2.4.22-r4.ebuild...
Fixed in alpha-sources-*.ebuild.
Fixed in arm-sources-2.4.19-r2.ebuild.
Fixed in mips-sources-*.ebuild.
Fixed in ck-sources-*.ebuild.
Fixed in ia64-sources-2.4.22-r2.ebuild...
Fixed in openmosix-*.ebuild.
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
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.
Fixed in rsbac-sources-2.4.20-r1.ebuild.
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?
check your mail, it went out today around midnight GMT.
All vulnerable kernels have been patched. The GLSA went out at around 23:50UTC
yesterday, so this is resolved.
