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