[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87r6krj1o1.fsf@mid.deneb.enyo.de>
Date: Fri, 21 Sep 2007 20:47:42 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Code Audit Labs <vulnhunt@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, vulnwatch@...nwatch.org,
bugtraq@...urityfocus.com
Subject: Re: 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/
Powered by blists - more mailing lists