Re: EXIF integer overflow again
On 12/12/13 17:07, Pierre Joye wrote:
> But generating it at runtime during the test run sounds like a good
> solution. While I am not sure yet about a good way to craft a TIFF
> to fit the crash requirements, we have no API to get the heap size
> (not sure it is displayed by bintools).
Not the heap size, the heap pointer, i.e. (size_t)ptr, the distance
between the start of address space and the pointer returned by
emalloc(). On Linux, malloc() will sometimes use brk(), which gives
you an address after .text, .data, etc., so it is dependent on the
size of the main binary (which could be Apache, php-fcgi, etc.) --
typically it is some tens of megabytes above the start of the address
space.
If malloc() decides to use mmap() instead, on a 64-bit system, the
address returned will typically be terabytes above the start of
address space, so the attack will be infeasible. Windows apparently
doesn't have brk(), so the attack there would probably be limited to
32-bit systems.
-- Tim Starling
Thread (6 messages)