[OFF-TOPIC] Re: [LUG.ro] Fw: Linux kernel mremap vulnerability

Tue, 06 Jan 2004 16:21:43 -0300

Algo que no llego a entender es porque si habiendo compiladores y
tambien patchs para gcc (ej: stackguard, memguard) para impedir en la
mayoría de los casos que se produzcan ataques por buffer overflow porque
todavía sigue siendo uno de los ataques mas comunes. El compilador gcc y
el kernel van de la mano, me extraña que no hayan hecho algo.

Las soluciones que lei se basan en detectar alteraciones en el return
code de la funcion, o directamente no permitirla en absoluto. Segun
dicen esto genera un overhead de un 6/7% ... muy caro tal vez para el
kernel?, pero no en para aplicaciones comunes en general. Otras
soluciones se basan en impedir ejecutar codigo binario en esa zona del
stack (entre el almacenamiento de variables locales y el return code).

Si alguien tiene mas info. para aportar, bienvenida. 

Salu2,
           Federico :-

El mar, 06-01-2004 a las 07:06, Pablo escribió:
> 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
> 