full-disclosure - (unsigned)-1 and large VM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

From: guninski at guninski.com (Georgi Guninski)
Subject: (unsigned)-1 and large VM

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