AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
December 2010

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2010.12.06 16:32 "Security vulnerability CVE-2010-3847", by <imipak@gmail.com>
2010.12.06 18:44 "Re: Security vulnerability CVE-2010-3847", by Lee Howard
2010.12.06 20:09 "Re: Security vulnerability CVE-2010-3847", by Tom Lane
2010.12.08 01:19 "Re: Security vulnerability CVE-2010-3847", by Lee Howard
2010.12.07 16:07 "Re: Security vulnerability CVE-2010-3847", by <imipak@gmail.com>

2010.12.08 01:19 "Re: Security vulnerability CVE-2010-3847", by Lee Howard

Tom Lane wrote:
> Lee Howard <faxguy@howardsilvan.com> writes:
>   
>> I've just now committed the in-line patch found on...
>>     
>
>   
>> http://bugzilla.maptools.org/show_bug.cgi?id=2228
>>     
>
> 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...
>>     
>
>   
>> http://bugzilla.maptools.org/show_bug.cgi?id=2140
>>     
>
>   
>> ... 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
0
[root@gollum libtiff]#

I suspect that this result with HEAD is satisfactory since the aim of 
the 3.9 patching was to avoid the crash.

Thanks,

Lee.