Message-ID: <Pine.LNX.4.44.0312020108250.587-100000@isec.pl>
From: ihaquer at isec.pl (Paul Starzetz)
Subject: [iSEC] Linux kernel do_brk() lacks argument bound checking

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Synopsis:  Linux kernel do_brk() lacks argument bound checking
Product:   Linux
Version:   up to 2.4.23, others
Vendor:	   http://www.kernel.org/

URL:       http://isec.pl/vulnerabilities/isec-0012-do_brk.txt
CVE:	   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0961
Author:    Paul Starzetz <ihaquer@...c.pl>
           Wojciech Purczynski <cliph@...c.pl>
Date:      December 1, 2003


Issue:
======

Critical security bug has been discovered in the Linux kernel within
do_brk() function that may lead to full compromise of vulnerable system.


Details:
========

The physical memory of a x86 machine running one of the recent Linux
kernels is managed in a simplified flat memory model. Each user process
may address a memory ranging from 0 up to TASK_SIZE bytes. Memory above
this limit is not accessible to the user and contains kernel code with
its data structures. User process is divided into logical sections,
called virtual memory areas. The kernel keeps tracks and manages user
process's virtual memory areas to provide proper memory management and
memory protection faults handling. More details of Linux memory
management are out of the scope of this article and can be found in [3].

The do_brk() is an internal kernel function that is called indirectly to
manage process's memory heap (brk), growing or shrinking it accordingly.
It is simplified version of mmap(2) system call that only handles
anonymous mappings (i.e. not initialized data). The function lacks of
bound checks of its parameters and may be exploited to create arbitrary
large virtual memory area, exceeding user accessible memory limit. Thus,
the kernel memory above this limit may become part of user process's
memory as visible to the kernel memory manager.

Typical memory layout of user process may look like:

bash$ cat /proc/self/maps
08048000-0804c000 r-xp 00000000 03:02 207935     /bin/cat
0804c000-0804d000 rw-p 00003000 03:02 207935     /bin/cat
0804d000-0804e000 rwxp 00000000 00:00 0
40000000-40015000 r-xp 00000000 03:02 207495     /lib/ld-2.3.2.so
40015000-40016000 rw-p 00014000 03:02 207495     /lib/ld-2.3.2.so
40016000-40017000 rw-p 00000000 00:00 0
40020000-40021000 rw-p 00000000 00:00 0
42000000-4212f000 r-xp 00000000 03:02 319985     /lib/tls/libc-2.3.2.so
4212f000-42132000 rw-p 0012f000 03:02 319985     /lib/tls/libc-2.3.2.so
42132000-42134000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0

The do_brk() function is called from within ELF and a.out loaders as
well as from brk(2) syscall. These are three different vectors which may
be used to exploit do_brk() bug. After successful exploitation process
memory may contain a large memory mapping, i.e.:

080a5000-c891d000 rwxp 00000000 00:00 0


Impact:
=======

Successful exploitation of do_brk() leads to full compromise of
vulnerable system, including gaining full uid 0 privileges, possibility
of kernel code and data structures modification as well as kernel-level
(ring0) code execution.

Tested and successfully exploited kernel versions include:

  o  2.4.20-18.9 as shipped with RedHat 9.0
  o  2.4.22 (vanila)
  o  2.4.22 with grsecurity patch

There is no known reliable workaround for this vulnerability except. We
recommend upgrading to the most recent kernel version (so far the 2.4.23
kernel) on all vulnerable systems.

Limiting maximum size of user process's data segment with ulimit -d
command provides some workaround for exploit based on brk system call.
However, there are at least two other attack vectors that can not be
disabled without patching the system.

We have succesfully created proof-of-concept exploit. Unfortunately we
guess that our exploit may have leaked to the underground.


Credits:
========

Paul Starzetz <ihaquer@...c.pl> has indenpendently discovered the bug,
Wojciech Purczynski <cliph@...c.pl> invented and provided numerous
techniques to automatically and efficiently exploit the bug.


References:
===========

[1] Intel Architecture Software Developer's Manual Volume 2 
    "Instruction Set Reference"

[2] Intel Architecture Software Developer's Manual Volume 3 
    "System Programming Guide"

[3] Daniel P. Bovet, Marco Cesati, 
    "Understanding the Linux Kernel"


- -- 
Paul Starzetz
iSEC Security Research
http://isec.pl/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/y8jRC+8U3Z5wpu4RAnHvAKDEC0/e5xr7s61wMSsr4XUDl5+S8ACfQTqe
CsfpNtUMoLW7xDS22JSAJP0=
=dpRp
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists