This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Traceroute exploit + story (fwd)


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      |
\--------------------------------/  \--------------------------------/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]