[Full-Disclosure] (unsigned)-1 and large VM
From: Georgi Guninski (full-disclosure@lists.netsys.com)
Date: 08/28/02
- Next message: Schmehl, Paul L: "[Full-Disclosure] Just a suggestion"
- Previous message: ATD: "[Full-Disclosure] Administrivia"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: full-disclosure@lists.netsys.com (Georgi Guninski) Date: Wed, 28 Aug 2002 18:10:28 +0300
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
- Next message: Schmehl, Paul L: "[Full-Disclosure] Just a suggestion"
- Previous message: ATD: "[Full-Disclosure] Administrivia"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
