This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Traceroute exploit + story (fwd)
- To: Chris Evans <chris at scary dot beasts dot org>
- Subject: Re: Traceroute exploit + story (fwd)
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Thu, 5 Oct 2000 16:36:26 -0400
- Cc: security-audit at ferret dot lmh dot ox dot ac dot uk, libc-alpha at sourceware dot cygnus dot com
- References: <Pine.LNX.4.21.0010051953300.10542-100000@ferret.lmh.ox.ac.uk>
On Thu, Oct 05, 2000 at 08:06:20PM +0100, Chris Evans wrote:
>
> Hey,
>
> Seriously cool. Someone managed to exploit that errant free() call found
> in LBL traceroute by Pekka and connected to Solar's work by me.
>
> I guess the slightest heap management flaw should be considered VERY
> DANGEROUS. Solar showed that you can fairly easily exploit overflow of
> something malloc()'ed. This shows that free() of something either not
> allocated, or already freed, can often be exploited.
>
> Something to bear in mind while auditing.
Two thoughts on one thing here...
> next will be searched at 0x00010101 bytes above p at the least or
> 0x00ffffff bytes above p at most. Unfortunately this will never lead
> to next being in addressable memory space so here the exploit attempt
> ends.
>
> I was talking this over with Scrippie and he told me to take a look
> at some of the runtime parameters of the malloc system. One of these
> was the environment variable MALLOC_TOP_PAD_ which is used to pad
> sbrk calls. The result of MALLOC_TOP_PAD_ being set to 1000000 is
> that more then just the 1024 bytes required by traceroute are
> allocated using sbrk. Now next could be in addressable memory. Time
> for the real exploit.
This, if you remember, is where I dead-ended. I didn't know about
this.
Is it just me, or does glibc have WAY TOO MANY environment variable
interactions?
<snip rant about hooks when i stupidly notice that his final exploit
didn't actually need them, so maybe they never worked at all. oops,
one hour down the drain.>
Even more so... there is a glibc bug here. My guess from reading the
twisted mess of versions of the sysdep stuff in glibc 2.1.x implies
that the version of __libc_enable_secure in
sysdeps/generic/enbl-secure.c is not actually used if libc is compiled
-DPIC (meaning shared here, I assume). Instead it happens in
_dl_sysdep_start:
/* Linux doesn't provide us with any of these values on the stack
when the dynamic linker is run directly as a program. */
#define SEE(UID, uid) if ((seen & M (AT_##UID)) == 0) uid = __get##uid()
SEE (UID, uid);
SEE (GID, gid);
SEE (EUID, euid);
SEE (EGID, egid);
__libc_enable_secure = uid != euid || gid != egid;
That one's just declared as:
int __libc_enable_secure;
instead of:
/* Safest assumption, if somehow the initializer isn't run. */
int __libc_enable_secure = 1;
I don't think this is exploitable, esp. since we do not seem to malloc
until afterwards... but perhaps this should be fixed.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/