|
Brought to you by:
Suppliers of:
|
|
|
| |
Traceroute is suid-root in most Linux/UNIX systems. Some versions of traceroute suffer from a heap-overflow problem that can be used by local users to crash the application, and possibly execute arbitrary code.
No exploit code is currently available. |
| |
Credit:
This information was provided by Chris Evans.
The original traceroute bug was discovered by: Pekka Savola
For more information about exploiting heap overflows, see Solar Designer's explanation: http://www.securityfocus.com/archive/1/71598
|
| |
Vulnerable systems:
Lawrence Berkeley National Laboratory's traceroute 1.4a5
Debian potato
RedHat 6.0,6.2
Caldera 2.4
Mandrake 7.0
Immune systems:
Lawrence Berkeley National Laboratory's traceroute 1.4a7
RedHat 7.0
Debian woody
SuSE 6.3,6.4
OpenBSD 2.7-stable (patch_branch), 2.8-beta
FreeBSD 3.3,3.5
Slackware 4.0,7.0,7.1
AIX 4.0
Digital Unix 3.2
HP-UX 10.20, 11.00
Running traceroute with the following parameters:
$ traceroute -g 1 -g 1
causes a segmentation fault. The fact that traceroute is setuid-root enables local users with execution permissions for traceroute, to possibly gain administrative privileges on the machine.
Technical Explanation
Looking at the code, there is a file "savestr.c", which contains a function savestr(). This savestr() function is essentially a strdup() function, but with the difference that an attempt is made to cut down on the number of malloc() calls. This is accomplished by malloc()'ing a large block and handing out pointers inside this block as savestr() is repeatedly called.
Unfortunately, the clients of the savestr() method seemed to treat savestr() like it was strdup() - i.e. all pointers returned must be free()'d or you have a leak. This is not the
case, so we have the flaw: free() called on a pointer not allocated by malloc().
Let's have a look at some cheesy ASCII diagram showing the block of memory
allocated by savestr():
-----------------------------------------------
| |
-----------------------------------------------
^ * ^
| |
address free()
returned called
by malloc() here (2nd
and 1st savestr() savestr call
call result)
The reason this is so serious is that the free() call will attempt to do a bit of free chunk management. This involves memory writes. The memory writes are controlled by a "malloc chunk" descriptor, which resides just before the address returned by malloc(), and passed by free(). Looking at the above diagram, the location of the descriptor used by the faulty free() called is marked by a "*". Bad news - that's in a region of memory controlled by the malicious user.
See the link below to Solar's advisory for better discussion on how control of the contents of a malloc chunk descriptor may be used to subvert a program.
|
|
|
|
|
