> (I suppose that if you use a signed *long* in a 64-bit system where longs
> are 64-bit, then expanding a signed 32-bit int to such a signed 64-bit long
> will result in the wrong value. But was that the case here?)
>

While this one 
(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0894) didn't use 
negative offsets, only out of bounds indexes that weren't checked by the 
programmer.

This one, did use negative indexes:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0986
More details: http://cxsecurity.com/issue/WLB-2008030020

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> clipka <ano### [at] anonymousorg> wrote:
>> Okay, let's do it a bit more specific:
>
>>     void fubar(int idx)
>>     {
>>       char c[1024];
>>       if (idx < 1024)
>>         fnord(c[idx]);
>>       else
>>         FAIL_SAFE();
>>     }
>
>>     void main()
>>     {
>>       fubar(INT_MAX+1);
>>     }
>
>> No out-of-bounds access? Look at the code again.
>
> But in the original post it was suggested that an array size of INT_MAX+1
> in the image file could cause this. Here the array size is just 1024 (which
> in this particular contest would have ostensibly been read from the image
> file.)

I was going from memory.  Sorry about that.  It's not the array size 
that's too big.  Just accessing elements outside of it.

>
> Unless there's an image file where there are actual index values specified.
>

Bingo.

FWIW, there's a group at the University of Oulu 
(https://www.ee.oulu.fi/research/ouspg/), next door to you, who do this 
all day long.  Try to break devices by sending specially crafted packets 
that don't respect the protocol specs.  They were really famous for a 
while in 2002, when they found out that every single device from every 
single network equipment vendor was vulnerable to denial-of-service 
attacks using SNMP.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

> The only situation that I can think of where an out-of-bounds access will
> probably happen is if pointers (and thus array indices) are 64-bit but
> the array size is wrongly a signed (32-bit) int. It then gets expanded
> to 64-bit when indexing the array, and ends up truly at negative addresses
> (from the array's start.)

You could also have the situation where the code is inconsistent 
regarding signed and unsigned (32-bit) values. Couldn't something like 
this break with a negative value of imageSize stored in the image file?

void LoadImageFromFile(unsigned int size);
void ReserveMemory(int size);

int headerSize = 1024;
int imageSize = readIntFromFile();
ReserveMemory(headerSize + imageSize);
LoadHeaderFromFile(headerSize);
LoadImageFromFile(imageSize);

Post a reply to this message