Re: [Full-disclosure] CAL-20070912-1 Multiple vendor produce handling AVI file vulnerabilities

* Code Audit Labs:

>     that's funny, the above code still can be bypassed because of
> incorrect check  order.
>
>     and example code
>     calloc(0x10000001, 0x10);
>
>     it will return NULL in winxp or gligc 2.5
>     it will return 0x10 sizes heap in glibc <2.5(maybe prior) or
> win2000 sp4

This bug has been fixed in GNU libc CVS in August 2002.  I've just
checked version 2.3.6, and it does return NULL on overflow.  There is,
however, a different version of calloc that GDB sees, but this is not
the real one invoked by application code.

On Windows, this bug depends on the Microsoft Visual C++ run-time
library.  As a result, it's not completely determined by the Windows
version alone.

By the way, the similar operator new[] issue that has been reported in
conjunction with that calloc issue:

  <http://cert.uni-stuttgart.de/advisories/calloc.php>

has allegedly been fixed by Microsoft as well, by throwing
std::bad_alloc.  G++ and libstdc++ are still vulnerable to
applications that perform unbounded allocations.  Over the years, it's
been debated again and again what the C++ standard says on this
matter, how large the performance impact would be, and so on, but no
one has created a patch (which would need to change the cross-vendor
C++ ABI, too).

The Ada Reference Manual does not preclude a fix, but I don't think
anyone has written a patch for GNAT.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/