> On 16/01/2013 11:59 AM, Kenneth wrote:
>> Wow, it seems that security updates for various pieces of 'standard'
>> Windows-related software are coming down fast and furious these days:
>> Firefox,
>> Java, Flash Player, Windows itself (well, my old XP version.) I'm
>> getting one or
>> the other of these on almost a daily basis. Cyber-criminals and
>> spammers must be
>> working overtime!
>
> Just because a security flaw has been discovered, does not necessarily
> imply that anybody has actually *exploited* it yet.
>
> It could well just be the QA people doing code reviews and finding bugs
> that way.

QA people?  You mean the one guy in India who quit last month and can't 
be replaced because there's a hiring freeze because the 3rd quarter 
results weren't good enough?

-- 
/*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

Francois Labreque <fla### [at] videotronca> wrote:

> > Orchid Win7 v1 <voi### [at] devnull> wrote:
> >> There appears to be plenty of software that incorrectly treats various
> >> size values as signed integers. (E.g., programs that malfunction on
> >> files larger than 2GB because they think the file size has become
> >> "negative".)
> >
> > Can you give me a scenario where that produces a buffer overflow?

> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0894

That didn't really answer my question.

-- 
                                                          - Warp

Post a reply to this message

Francois Labreque <fla### [at] videotronca> wrote:
> In the case of the BMP flaw, the leaked Windows 2000 source code showed 
> that the DLL was using a signed int to read an offset value that was 
> unsigned in the file format, so by crafting a special BMP file you would 
> have the DLL jump to a negative offset, and outside of the actual data 
> structure it was supposed to read.

In 2's complement representation MAX_INT+1 has the exact same bits in
both signed and unsigned forms. How do you get outside the array with
that value?

(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?)

-- 
                                                          - Warp

Post a reply to this message

Am 18.01.2013 16:58, schrieb Warp:
> Francois Labreque <fla### [at] videotronca> wrote:
>> In the case of the BMP flaw, the leaked Windows 2000 source code showed
>> that the DLL was using a signed int to read an offset value that was
>> unsigned in the file format, so by crafting a special BMP file you would
>> have the DLL jump to a negative offset, and outside of the actual data
>> structure it was supposed to read.
>
> In 2's complement representation MAX_INT+1 has the exact same bits in
> both signed and unsigned forms. How do you get outside the array with
> that value?

That's wrong. In 2's complement representation, MAX_INT+1 has NO bit 
representation at all. What you get instead if you interpret the 
respective unsigned representation as signed is MIN_INT.

So take an array with a limited size, an "int" as an index into that 
array, a check whether that index into that array is smaller than the 
array's size - and you have the recipe for a stack overflow or similar 
(unless you also remember to check whether the index is non-negative).

Post a reply to this message

>> In 2's complement representation MAX_INT+1 has the exact same bits in
>> both signed and unsigned forms. How do you get outside the array with
>> that value?
>
> That's wrong. In 2's complement representation, MAX_INT+1 has NO bit
> representation at all. What you get instead if you interpret the
> respective unsigned representation as signed is MIN_INT.

Erm... don't you mean -1?

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> >> In 2's complement representation MAX_INT+1 has the exact same bits in
> >> both signed and unsigned forms. How do you get outside the array with
> >> that value?
> >
> > That's wrong. In 2's complement representation, MAX_INT+1 has NO bit
> > representation at all. What you get instead if you interpret the
> > respective unsigned representation as signed is MIN_INT.

> Erm... don't you mean -1?

No. int(-1) has the same bit representation as MAX_UINT.

-- 
                                                          - Warp

Post a reply to this message

Am 18.01.2013 18:47, schrieb Orchid Win7 v1:
>>> In 2's complement representation MAX_INT+1 has the exact same bits in
>>> both signed and unsigned forms. How do you get outside the array with
>>> that value?
>>
>> That's wrong. In 2's complement representation, MAX_INT+1 has NO bit
>> representation at all. What you get instead if you interpret the
>> respective unsigned representation as signed is MIN_INT.
>
> Erm... don't you mean -1?

No. That would be MAX_UINT.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> So take an array with a limited size, an "int" as an index into that 
> array, a check whether that index into that array is smaller than the 
> array's size - and you have the recipe for a stack overflow or similar 
> (unless you also remember to check whether the index is non-negative).

There's no index value that *could* be smaller than MIN_INT, so you would
have a bug certainly (the program wrongly thinks that all indices are
outside the array), but still no out-of-bounds access.

Even if the array size is (interpreted as) something larger than MIN_INT,
thus allowing for indices that are smaller than it, it would still bug
but not access out of the array (because negative indices "wrap around"
when they are converted to memory offsets, ending up at the same place
as the unsigned index with the same bit pattern.)

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.)

-- 
                                                          - Warp

Post a reply to this message

Am 18.01.2013 19:30, schrieb Warp:
> clipka <ano### [at] anonymousorg> wrote:
>> So take an array with a limited size, an "int" as an index into that
>> array, a check whether that index into that array is smaller than the
>> array's size - and you have the recipe for a stack overflow or similar
>> (unless you also remember to check whether the index is non-negative).
>
> There's no index value that *could* be smaller than MIN_INT, so you would
> have a bug certainly (the program wrongly thinks that all indices are
> outside the array), but still no out-of-bounds access.

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.

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.)

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

-- 
                                                          - Warp

Post a reply to this message