US-CERT Vulnerability Note VU#162289

[Robert C. Seacord]

Dave,

I made at least one change you suggested:

#include <stdio.h>

void f(char *buf)  {
  unsigned int len = 0xFFFFFF00u;
 
  if (buf+len < buf) puts("true");

}

int main(void) {
    char buffer[100];
    printf("buffer addr = %p.\n", buffer);
    f(buffer);
    return 0;
}

And compiled with flags:

/O2 /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" 
/FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W4 /nologo /c /Wp64 
/Zi /TC /errorReport:prompt

The output of this program is:

buffer addr = 0012FF18.
true

The reason the len is so high is to force an overflow when added to 
0x0012FF18.

BTW, I also tried compiling this as a C++ program under visual studio 
and got the same result.

rCs


> Robert C. Seacord wrote on :
>
>   
>> Specifically with regards to MSVC 2005, I thought Chad had already
>> checked this and found that it did not exhibit this behavior.  I just
>> tested the following program. 
>>
>> #include <stdio.h>
>>
>> void f(char *buf)  {
>>   unsigned int len = len = 0xFFFFFF00;
>>     
>
>   I'm sure you didn't mean to do that, but I doubt it affects the results.
>
>   BTW, that's a very different number from (1 << 30).  How about trying again
> with a 'u' suffix?  Or with something that doesn't have the sign bit set?
>
>     cheers,
>       DaveK
>