bugtraq - Re: CAL-20070912-1 Multiple vendor produce handling AVI file vulnerabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<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, bugtraq@...urityfocus.com,
	vulnwatch@...nwatch.org
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.