37292 2004-01-05 05:28 0000 Critical kernel mremp vulnerability 2004-01-09 03:54:08 0000 1 1 1 Unclassified Gentoo Linux Security unspecified All Linux RESOLVED FIXED http://isec.pl/vulnerabilities/isec-0012-mremap.txt P1 critical --- 1 fbusse@gmx.de security@gentoo.org centic@gentoo.org cycloon@is-root.org iggy@gentoo.org m.debruijne@matrict.nl pebenito@gentoo.org vorlon@gentoo.org x86-kernel@gentoo.org fbusse@gmx.de 2004-01-05 05:28:32 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 fbusse@gmx.de 2004-01-05 05:28:32 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­ 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----- fbusse@gmx.de 2004-01-05 06:32:06 0000 Kernel 2.4.24 has been released to address this vulnerability: http://www.kernel.org/pub/linux/kernel/v2.4/ChangeLog-2.4.24 solar@gentoo.org 2004-01-05 08:51:07 0000 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 vorlon@gentoo.org 2004-01-05 09:33:32 0000 Duplicate of BUG #37293 I guess, patch from kernel 2.4.24 given there. johnm@gentoo.org 2004-01-05 09:44:21 0000 im currently wortking on this now. please expect glsa/bumps within the next hour or so johnm@gentoo.org 2004-01-05 09:56:54 0000 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 johnm@gentoo.org 2004-01-05 09:57:53 0000 Created an attachment (id=23194) mremap-CAN-2003-0985.patch vapier@gentoo.org 2004-01-05 10:04:19 0000 *** Bug 37293 has been marked as a duplicate of this bug. *** solar@gentoo.org 2004-01-05 10:11:29 0000 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 kerframil@gmail.com 2004-01-05 10:24:40 0000 Created an attachment (id=23196) Revised mremap patch to solve patching issues Apparently solves the matter of rejects for some people. scox@sig11.org 2004-01-05 10:29:52 0000 hardened-sources-2.4.22-r2 commited cycloon@is-root.org 2004-01-05 10:55:49 0000 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" pebenito@gentoo.org 2004-01-05 11:05:02 0000 selinux-sources-2.4.24 is committed. I reversed the mremap patch and used the revised mremap patch. scox@sig11.org 2004-01-05 11:06:04 0000 vanilla-sources-2.4.24 commited. vanilla mremap fix has been kept. plasmaroo@gentoo.org 2004-01-05 11:14:53 0000 Bug 37317 tracks the RTC issue. plasmaroo@gentoo.org 2004-01-05 13:14:07 0000 Added development-sources-2.6.1_rc1.ebuild along with the necessary 2.6 patch; removed development-sources-2.6.0_beta7.ebuild... plasmaroo@gentoo.org 2004-01-05 14:23:49 0000 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... plasmaroo@gentoo.org 2004-01-05 15:07:49 0000 Fixed grsec-sources-2.4.23.1.9.13.ebuild and grsec-sources-2.4.23.2.0_rc4.ebuild. plasmaroo@gentoo.org 2004-01-05 16:31:26 0000 Bumped to and fixed in wolk-sources-4.10_pre7-r2.ebuild and wolk-sources-4.9-r3.ebuild. plasmaroo@gentoo.org 2004-01-06 07:19:06 0000 Fixed in gentoo-sources-2.4.22-r2.ebuild and gentoo-sources-2.4.20-r10.ebuild. plasmaroo@gentoo.org 2004-01-06 07:51:05 0000 Fixed in ac-sources-2.4.22-r4.ebuild... plasmaroo@gentoo.org 2004-01-06 08:17:44 0000 Fixed in alpha-sources-*.ebuild. plasmaroo@gentoo.org 2004-01-06 08:41:51 0000 Fixed in arm-sources-2.4.19-r2.ebuild. plasmaroo@gentoo.org 2004-01-06 08:56:02 0000 Fixed in mips-sources-*.ebuild. plasmaroo@gentoo.org 2004-01-06 10:01:13 0000 Fixed in ck-sources-*.ebuild. plasmaroo@gentoo.org 2004-01-06 13:04:06 0000 Fixed in ia64-sources-2.4.22-r2.ebuild... plasmaroo@gentoo.org 2004-01-06 14:44:18 0000 Fixed in openmosix-*.ebuild. billk@iinet.net.au 2004-01-06 15:33:50 0000 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 plasmaroo@gentoo.org 2004-01-06 16:03:17 0000 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. plasmaroo@gentoo.org 2004-01-06 16:43:15 0000 Fixed in rsbac-sources-2.4.20-r1.ebuild. wpan03@gmail.com 2004-01-08 19:40:26 0000 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? genone@gentoo.org 2004-01-08 19:54:44 0000 check your mail, it went out today around midnight GMT. plasmaroo@gentoo.org 2004-01-09 03:54:08 0000 All vulnerable kernels have been patched. The GLSA went out at around 23:50UTC yesterday, so this is resolved. 23194 2004-01-05 09:57 0000 mremap-CAN-2003-0985.patch mremap-CAN-2003-0985.patch text/plain LS0tIGxpbnV4L21tL21yZW1hcC5jLm9yaWcJMjAwNC0wMS0wNSAxNzowMToyMS4zODIxMDQxMjAg KzAwMDAKKysrIGxpbnV4L21tL21yZW1hcC5jCTIwMDQtMDEtMDUgMTc6MTU6MjUuNjg5NzQ5ODQ4 ICswMDAwCkBAIC0zMTUsNiArMzE1LDEwIEBACiAJb2xkX2xlbiA9IFBBR0VfQUxJR04ob2xkX2xl bik7CiAJbmV3X2xlbiA9IFBBR0VfQUxJR04obmV3X2xlbik7CiAKKwkvKiBEb24ndCBhbGxvdyB0 aGUgZGVnZW5lcmF0ZSBjYXNlcyAqLworCWlmICghKG9sZF9sZW4gfCBuZXdfbGVuKSkKKwkJZ290 byBvdXQ7CisKIAkvKiBuZXdfYWRkciBpcyBvbmx5IHZhbGlkIGlmIE1SRU1BUF9GSVhFRCBpcyBz cGVjaWZpZWQgKi8KIAlpZiAoZmxhZ3MgJiBNUkVNQVBfRklYRUQpIHsKIAkJaWYgKG5ld19hZGRy ICYgflBBR0VfTUFTSykK 23196 2004-01-05 10:24 0000 Revised mremap patch to solve patching issues mremap-CAN-2003-0985.patch text/plain LS0tIGxpbnV4L21tL21yZW1hcC5jLm9yaWcJMjAwNC0wMS0wNSAxNzowMToyMS4zODIxMDQxMjAg KzAwMDAKKysrIGxpbnV4L21tL21yZW1hcC5jCTIwMDQtMDEtMDUgMTc6MTU6MjUuNjg5NzQ5ODQ4 ICswMDAwCkBAIC0yNzAsNiArMjcwLDEwIEBACiAJb2xkX2xlbiA9IFBBR0VfQUxJR04ob2xkX2xl bik7CiAJbmV3X2xlbiA9IFBBR0VfQUxJR04obmV3X2xlbik7CiAKKwkvKiBEb24ndCBhbGxvdyB0 aGUgZGVnZW5lcmF0ZSBjYXNlcyAqLworCWlmICghKG9sZF9sZW4gfCBuZXdfbGVuKSkKKwkJZ290 byBvdXQ7CisKIAkvKiBuZXdfYWRkciBpcyBvbmx5IHZhbGlkIGlmIE1SRU1BUF9GSVhFRCBpcyBz cGVjaWZpZWQgKi8KIAlpZiAoZmxhZ3MgJiBNUkVNQVBfRklYRUQpIHsKIAkJaWYgKG5ld19hZGRy ICYgflBBR0VfTUFTSykK