[LUG.ro] Fw: Linux kernel mremap vulnerability

Pablo lugro@lugro.org.ar
Tue, 6 Jan 2004 07:06:22 -0300


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