2010.12.08 01:19 "Re: [Tiff] Security vulnerability CVE-2010-3847", by Lee Howard
I've just now committed the in-line patch found on...
I find the patch given in #2228 pretty unsatisfactory, as it's throwing away image quality to produce what seems no better than a cargo-cult solution to the problem. Turning off fancy upsampling doesn't affect the number of output pixels libjpeg produces. It would cause it to not *read* adjacent rows for averaging purposes, but if that causes a segfault then your problem is elsewhere. It is certainly not fixing the problem explained in #2140, which is that the required output buffer size is underestimated.
Very well. I've backed-out (undone) the patch.
For what it's worth, the various distros (well, SUSE at least) were applying that patch as well as the one from 2140.
I'm not sure if that small change resolves CVE-2010-3087. The various distros are using Tom Lane's patch on...
... as a resolution to CVE-2010-3087.
You can see on the bug report that Frank seemed to object to Tom's proposal on Bug 2140, so I think for the moment we're stuck there needing some further response from Frank on this. (Frank?)
For the record, *I* don't much like that patch either :-). I think it's OK for the limited purpose of stopping core dumps, but it's far from resolving all the issues complained of in #2140.
Thanks for your comments.
I've applied and committed the 2140 patch to the 3.9 branch.
The patch does not apply at all to tif_strip.c in HEAD (4.0). However, the segfault does not occur there...
[root@gollum libtiff]# tools/tiffcmp -l /tmp/libtiffpic/quad-jpeg.tif /tmp/libtiffpic/quad-jpeg.tif ; echo $? TIFFReadScanline: scanline oriented access is not supported for downsampled JPEG compressed images, consider enabling TIFF_JPEGCOLORMODE as JPEGCOLORMODE_RGB..
/tmp/libtiffpic/quad-jpeg.tif: EOF at scanline 0
I suspect that this result with HEAD is satisfactory since the aim of the 3.9 patching was to avoid the crash.