[LUG.ro] RE:[LUG.ro] Fw: Linux kernel mremap vulnerability
lugro@lugro.org.ar
lugro@lugro.org.ar
Tue, 06 Jan 2004 10:32:31 -0300
segun lo que lei en pcworld.com y linux headquarters las dos ultimas fallas (la del ataque a debian y la del mremap la incluian en el kernel 26 que ya tambien si se fijan tiene un prepatch actualizado hoy mismo
red hat y la empresa isec que lo descubrio lo sabian desde el 2.4.20 del rh9
salu2
-- Mensaje Original --
Enviado por: Pablo <paa@argentina.com>
Fecha: 06/01/2004 10:06:22
Para: <lugro@lugro.org.ar>
Título: [LUG.ro] Fw: Linux kernel mremap vulnerability
2 grandes agujeros en poco tiempo...mmmh
Sera hora de "tirar" el 2.4 y pasarse al 2.6 ?!
Saludos. Pablo.
----- Original Message -----
From: "Paul Starzetz" <ihaquer@isec.pl>
Sent: Monday, January 05, 2004 9:30 AM
Subject: Linux kernel mremap vulnerability
> -----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-----
>
>
_______________________________________________
Lugro mailing list
Lugro@lugro.org.ar
http://www.lugro.org.ar/mailman/listinfo/lugro
__________________________________________________
Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar
Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para actualizar tu PC.
http://www.ciudad.com.ar/ar/servicios/ie/