bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: Possible bug in the memory chunk management.]


From: Ehud Tenenbaum
Subject: [Fwd: Possible bug in the memory chunk management.]
Date: Sun, 17 Feb 2002 23:42:00 +0200

-- 
------------
Ehud Tenenbaum
C.T.O & Project Manager 
2xs LTD. 
Tel: 972-9-9519980
Fax: 972-9-9519982
E-Mail: address@hidden
------------ 
                                 Have A Safe Day
--- Begin Message --- Subject: Re: Possible bug in the memory chunk management. Date: Sun, 17 Feb 2002 23:40:29 +0200
Hey again...

You are right, we did made a mistake but nevertheless you missed
the point, Hence even if we will make buf_h = calloc(1, 7);
the problem is with the second loop who overwrite the buffer.

Please take a second look at the source (change buf_h = calloc(1, 6) to
buf_h = calloc(1, 7); ) and still the output will be buf_h[4] = 1
This been tested on slackware linux 8.0.

Thanks for the correction, looking forward to see your reply.

2xs Security team.



Andreas Jaeger wrote:
> 
> Ehud Tenenbaum <address@hidden> writes:
> 
> > Hey,
> >
> > We would like to confirm a bug we in 2xs LTD came across.
> >
> > Problem:
> >
> > When you allocate a multidimensional array for pointers dynamically
> > and point these dynamically allocated pointers to also dynamically
> > allocated variables, then allocation or subsequent variables will
> > overwrite parts of the first variables.
> > We attached a Proof-Of-concept code in-order to show
> > exactly what we mean. After short auditing of the calloc/malloc code
> > (malloc suffer from same the problem) we think its not bug in there,
> > we believe the problem is inside of the memory chunk management but
> > yet we could be wrong.
> >
> > Work around:
> >
> > Well there is a work around you need to make the first buffer
> > to a static one and by that it wont collide.
> >
> > Should you have any more questions or comments dont hesitate to contact
> > us:
> >
> > Ehud Tenenbaum <address@hidden> CTO, Project Manager.
> > Izik Kotler <address@hidden> Senior Programmer.
> > Mixter <address@hidden> Senior Programmer.
> 
> Your program is broken, you allocate:
> 
> >   buf_h = calloc(1, 6);
> 
> a buffer with 6 entries, from 0 to 5, and access buf_h[6] later on.
> 
> Accessing memory outside the allocated range is not allowed, you just
> overwrote internal memory of glibc's malloc implementation.
> 
> Andreas
> --
>  Andreas Jaeger
>   SuSE Labs address@hidden
>    private address@hidden
>     http://www.suse.de/~aj

-- 
------------
Ehud Tenenbaum
C.T.O & Project Manager 
2xs LTD. 
Tel: 972-9-9519980
Fax: 972-9-9519982
E-Mail: address@hidden
------------ 
                                 Have A Safe Day
/*
  example for the bug.
*/

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>

char **buf_h;
char **buf_e;

int main() {
   int ctr, i;

   buf_h = calloc(1, 7);
   buf_e = calloc(1, 12);

   if ((!buf_h) || (!buf_e))
     return -1;

   ctr = 0;

   for (i = 512; i < 20000; i *= 2) {
      ctr++;

      buf_h[ctr] = calloc(1, (i * 2));

      if (!buf_h[ctr])
        perror("buf_h");

      memset(buf_h[ctr], 'A', ((i * 2) - 1));
      printf("** buf_h (%d) length is %d bytes\n", ctr, strlen(buf_h[ctr]));
   }

   printf("** buf_h[4] is equal's %d bytes\n", strlen(buf_h[4]));

   for (i = 0; i < 6; i++) {
      buf_e[i] = calloc(1, 100);

      memset(buf_e[i], 0x41, 1);

      if (!buf_e[i]) 
        perror("buf_e");      
   }

   printf("** after loop buf[4] is %d\n", strlen(buf_h[4]));
}

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]