[prev in list] [next in list] [prev in thread] [next in thread] 

List:       full-disclosure
Subject:    [Full-Disclosure] (unsigned)-1 and large VM
From:       Georgi Guninski <guninski () guninski ! com>
Date:       2002-08-28 15:10:28
[Download RAW message or body]

Potential vulnerability on 64 bit if a lot of virtual memory is present

Can't test this personally, but may turn exploitable.

The following code is somewhat common in some apps:
(a little modified from apache)
-----------------------
1  char *strdup (const char *str)
2  {
3  char *dup;
4  unsigned int len; // int len; also works
5  len=strlen(str);	
6  if (!(dup = (char *) malloc(len + 1)))
7     return NULL;
8  dup = strcpy(dup, str);
9
10  return dup;
11}
-----------------------

Consider the following scenario:
str is large - 4GB-1.
strlen(str) returns (unsigned)-1 so len=(unsigned)-1;
on line 6 maloc(-1+1)==malloc(0) has chance of succeeding and on line
8 strcpy definitely screws some of the heap unless it segfaults.

Some difficulties include:
1. One should be able to supply in VM string of size (unsigned)-1 which is
4GB-1.
2. malloc(0) should succeed (works on linux and windoze)
3. strcpy should not segfault (probably possible if dup < str)
4. misc problems with the heap

Can someone with a lot of VM (4+GB) confirm or deny creating a string with
size (unsigned)-1 is possible?


Georgi Guninski
http://www.guninski.com

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
[prev in list] [next in list] [prev in thread] [next in thread]