On 2018-08-14 17:27:29, Brian May wrote:
> I have been trying to reproduce this bug (buffer overflow), but instead
> I get increasing memory usage until my computer crashes. With versions
> from Jessie, Stretch, and Sid. So maybe another security issue?
>
> I note that CVE-2017-11613 and CVE-2018-5784 can use unbounded
> memory. However these are marked as fixed everywhere but Stretch.
>
> As far as I can tell, the relevant code is:
>
> uint64* newcounts;
>
> ...
>
> newcounts = (uint64*) _TIFFCheckMalloc(tif, nstrips, sizeof (uint64),
> "for chopped \"StripByteCounts\" array");
>
> ...
>
> for (strip = 0; strip < nstrips; strip++) {
> ...
> newcounts[strip] = stripbytes;
> ...
> }
>
> However, I cannot see how this could cause a buffer overflow
> condition. We appear to allocate nstrips uint64, and then use nstrips
> uint64.
I can't reproduce this either in a jessie VM:
[...]
ii libtiff-tools 4.0.3-12.3+deb8u6 amd64
TIFF manipulation and conversion tools
ii libtiff5:amd64 4.0.3-12.3+deb8u6 amd64
Tag Image File Format (TIFF) library
vagrant@jessie:~$ valgrind tiff2pdf poc1
==17408== Memcheck, a memory error detector
==17408== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17408== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==17408== Command: tiff2pdf poc1
==17408==
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and
calculating from imagelength.
II*TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and
calculating from imagelength.
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and
calculating from imagelength.
%PDF-1.1
%âãÏÓ
1 0 obj
<<
/Type /Catalog
/Pages 3 0 R
>>
endobj
2 0 obj
<<
/CreationDate (D:20180827145928)
/ModDate (D:20180827145928)
/Producer (libtiff / tiff2pdf - 20120922)
/Title (miniswhite-1c-1b.tiff)
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [ 4 0 R ]
/Count 1
>>
endobj
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 65046 (0xfe16) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored.
TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and
ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as
ExtraSamples..
TIFFReadDirectory: Warning, Bogus "StripByteCounts" field, ignoring and
calculating from imagelength.
tiff2pdf: No support for poc1 with 254 samples per pixel.
tiff2pdf: An error occurred creating output PDF file.
==17408==
==17408== HEAP SUMMARY:
==17408== in use at exit: 0 bytes in 0 blocks
==17408== total heap usage: 106 allocs, 106 frees, 35,811 bytes allocated
==17408==
==17408== All heap blocks were freed -- no leaks are possible
==17408==
==17408== For counts of detected and suppressed errors, rerun with: -v
==17408== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Now, this could be because it's valgrind and not ASAN. But still - if
compiling with ASAN triggers the bug, I fail to see how this affects us:
our package is *not* compiled with it, and, as such, doesn't
misbehave. But just for the fun of it, I *did* try to recompile the
package with ASAN, as per:
https://wiki.debian.org/LTS/Development/Asan
And I still can't trigger the bug.
For what it's worth, the original bug report mentions Ubuntu 16.04 and
v4.0.9, compiled with clang:
http://bugzilla.maptools.org/show_bug.cgi?id=2808
So the next step would probably be to try
to reproduce with clang, but at this point I think we can safely say
we're just not affected. It's perfectly possible this bug was introduced
later or somewhat fixed as collateral in another patch of ours.
Brian, are you sure you're getting those failures in jessie? Which
architecture? Here my tests were done in a VirtualBox VM using an up to
date Debian jessie amd64 box.
In the meantime, I've marked the CVE as not-affected for us and we can
move on. If someone else finds otherwise, we can obviously bring this
back on track, and I'll be happy to take a second look.
Cheers!
A.
