Full Disclosure mailing list archives
(unsigned)-1 and large VM
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
Current thread:
- (unsigned)-1 and large VM Georgi Guninski (Aug 28)