what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

do_brk.txt

do_brk.txt
Posted Dec 3, 2003
Authored by Wojciech Purczynski, Paul Starzetz | Site isec.pl

Detailed information on the linux kernel v2.4 prior to v2.4.23 local root vulnerability in the do_brk() kernel function. Kernels 2.4.20-18.9, 2.4.22 (vanilla), and 2.4.22 with grsecurity patch are confirmed vulnerable.

tags | advisory, kernel, local, root
systems | linux
SHA-256 | 43a76479ec2e92c678e1e79c86fa11a5609b490ba6e29b4d220c64300a875126

do_brk.txt

Change Mirror Download
-----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@isec.pl>
Wojciech Purczynski <cliph@isec.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@isec.pl> has indenpendently discovered the bug,
Wojciech Purczynski <cliph@isec.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-----

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close