> 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:
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.
> 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.
[ reply ]