Re: vulnerabilities in this code chunk

[Jonathan Leffler <jleffler () us ibm com>]

> ----- Message from erk_3 () hotmail com on 21 Jun 2007 22:41:04 -0000 -----
> I am trying to find all the vuln's in this code chunk, and the only 
> thing I can come up with is a null pointer dereference.  Assume data
> and data_len are user controlled.
> Null pointer happens when passing in a negative number.

You can't pass a negative number in an unsigned int - all numbers are 
non-negative.
And what do you mean by 'null pointer happens'?

> I was 
> looking hard at the memset functions but I couldn't come up with 
anything. 
> Anyone else see anything here?
>
> char *copy_data(char *data, unsigned int data_len)
> { 
> unsigned int header_size = 8;
> char *buf;
> if (!(buf = malloc(data_len + header_size))) 
> {
> return NULL; 
> }
> memcpy(buf, "HEADER: ", 8);

Why not use header_size consistently?

> memcpy(buf + 8, data, data_len);
> return buf;
> }

Assuming 32-bit integers and data_len = 0xFFFFFFFC, this code requests 4 
bytes of data from malloc, and then tramples over 4GB of data.  Something 
is going to crash.

Similarly, if data_len is 0xFFFFFFF8, the code generates a request for 0 
bytes of data.  Some versions of malloc() -- I'm told that Windows is one 
such -- will return a valid pointer (rather than a null pointer) to zero 
bytes of usable space.  Crash again.  Numbers just a bit smaller than 
0xFFFFFFF8 are more likely to request too much memory and the malloc() 
should return a null pointer.

-- 
Jonathan Leffler (jleffler () us ibm com)
STSM, Informix Database Engineering, IBM Information Management Division
4100 Bohannon Drive, Menlo Park, CA 94025-1013
Tel: +1 650-926-6921    Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"