It was reported that python-pillow 3.1.0 when linked against libtiff >= 4.0.0 may overflow a buffer when reading a specially crafted tiff file. libtiff >=4.0.0 changed the return type of TIFFScanlineSize from int32 to machine dependent int32|64. If the scanline is sized so that it overflows an int32, it may be interpreted as a negative number, which will then pass the size check in TiffDecode.c line 236. To do this, the logical scanline size has to be > 2gb. If the size of allocated buffer is 64k, any image data over 64k is written over the heap, causing a segfault. Original bug report (contains reproducer): https://bugzilla.redhat.com/show_bug.cgi?id=1298648
Introduced via the following commit: https://github.com/python-pillow/Pillow/commit/e782fe721e0156de9636e78cd881d9f9e7e6ce50
RHEL7 is affected. However, the sample reproducer image was compressed in a format that our python-pillow does not support. For testing purposes, I've backported https://github.com/python-pillow/Pillow/commit/a130c45990578a1bb0a6a000ed1b110e27324910 and can see the crash. Although I failed to do so, it may be possible to create an image that would trigger this image using a different, supported compression algorithm.
python-imaging on RHEL5 and 6 is not linked to and does not support libtiff > 4.0.0. Since this issue requires the libtiff 4.0.0 64bit changes and they don't ship the vulnerable image processing code, they are not vulnerable.
Acknowledgements: Red Hat would like to thank the Pillow project for reporting this issue. Upstream acknowledges FourOne as the original reporter.