A security issue in libtiff has been announced on December 26: http://openwall.com/lists/oss-security/2015/12/26/7 No fix is available yet. Mageia 5 is also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA5TOO
Severity: normal => critical
OpenSuSE has issued an advisory for this on January 24: http://lists.opensuse.org/opensuse-updates/2016-01/msg00078.html
Unless the fix is the same for both, I think someone at OpenSuSE got this confused with CVE-2014-8128. See: https://bugzilla.suse.com/show_bug.cgi?id=942690 https://build.opensuse.org/request/show/353699 https://build.opensuse.org/package/rdiff/openSUSE:13.2:Update/tiff?linkrev=base&rev=4
URL: (none) => http://lwn.net/Vulnerabilities/673471/
Assigning to packagers collectively. If working on it, please assign the bug report to yourself.
Assignee: bugsquad => pkg-bugs
OpenSuSE has issued an advisory on April 17: https://lists.opensuse.org/opensuse-updates/2016-04/msg00064.html This fixes a new issue, CVE-2016-3186. If it really only affects the gif2tiff tool and not the library, as the description says, then it's not really important. Also, several, presumably unfixed, issues have been reported on oss-security (and supposedly to upstream) recently, so there may be more fixes coming.
Summary: libtiff new security issue CVE-2015-7554 => libtiff new security issues CVE-2015-7554 and CVE-2016-3186 (and possibly others)
CVE-2016-6223 has been assigned for an issue supposedly fixed in libtiff's version control repository: http://openwall.com/lists/oss-security/2016/07/14/4 I'm waiting for the next version of libtiff, which will hopefully contain fixes for these issues and several others that I alluded to in the last comment but haven't specifically listed here.
Summary: libtiff new security issues CVE-2015-7554 and CVE-2016-3186 (and possibly others) => libtiff new security issues CVE-2015-7554, CVE-2016-3186, and CVE-2016-6223 (and possibly others)
In the GitHub mirror, I see the CVE-2016-6223 commit, as well as ones labeled with CVE-2016-5321, CVE-2016-5323, and CVE-2016-5875. There may be other CVEs fixed that aren't labeled with the CVE in the commit message (as the CVE-2016-6223 one wasn't). https://github.com/vadz/libtiff/commits/master
LWN reference for... CVE-2016-5314 CVE-2016-5316 CVE-2016-5317 CVE-2016-5320 CVE-2016-5875: http://lwn.net/Vulnerabilities/695692/ fixed in this openSUSE advisory from July 27: https://lists.opensuse.org/opensuse-updates/2016-07/msg00087.html
openSUSE's update actually includes 3 upstream patches that fix CVE-2016-5314, CVE-2016-5317, and CVE-2016-5875, according to their changelog. Not sure where they got the other two CVEs from. https://build.opensuse.org/package/rdiff/openSUSE:13.2:Update/tiff?linkrev=base&rev=7
SuSE's bugzilla says: "CVE-2016-5875 (buffer overrun in PixarLogDecode()) is CVE-2016-5314 (PixarLogDecode() out-of-bound writes) which causes CVE-2016-5320" and it looks like CVE-2016-5320 and CVE-2016-5875 are fixed by the same patch.
I guess CVE-2016-5314 also gets fixed by the same patch. I missed the other two CVEs, which actually are in their changelog. So, three CVEs with one patch explains 5 CVEs and 3 patches. Bottom line is this just needs to be resynced with upstream, which should have all of these fixes.
RedHat advisory for several CVEs from August 2: https://rhn.redhat.com/errata/RHSA-2016-1546.html
LWN reference for... CVE-2015-8668 CVE-2016-3632 CVE-2016-3945 CVE-2016-3990 CVE-2016-3991: http://lwn.net/Vulnerabilities/696207/
LWN reference for CVE-2016-5315 and CVE-2016-532[1-3]: http://lwn.net/Vulnerabilities/698795/
LWN reference for CVE-2016-3623 and CVE-2016-6223: http://lwn.net/Vulnerabilities/699684/
Hi, Just to add that the project URL is no more http://www.remotesensing.org/libtiff/ but http://www.simplesystems.org/libtiff/ (See https://en.wikipedia.org/wiki/Libtiff, section "Website hijacking"). Best regards, Nico.
CC: (none) => nicolas.salguero
David, with all those CVEs pending, do you prefer we wait for version 4.0.7 or can I update our version to the latest CVS commit (it seems trying to cherry-pick all the commits related to a CVE is a bit hard)?
(In reply to Nicolas Salguero from comment #16) > David, with all those CVEs pending, do you prefer we wait for version 4.0.7 > or can I update our version to the latest CVS commit (it seems trying to > cherry-pick all the commits related to a CVE is a bit hard)? Yes I was planning to update to the latest CVS, but never got around to it. Feel free to update it. A 4.0.7 would be a lot more convenient, but I have no idea when that's planned.
Done for Mga5 and Cauldron. Suggested advisory: ======================== The updated packages fix security vulnerabilities: The _TIFFVGetField function in tif_dir.c in libtiff 4.0.6 allows attackers to cause a denial of service (invalid memory write and crash) or possibly have unspecified other impact via crafted field data in an extension tag in a TIFF image. (CVE-2015-7554) Heap-based buffer overflow in the PackBitsPreEncode function in tif_packbits.c in bmp2tiff in libtiff 4.0.6 and earlier allows remote attackers to execute arbitrary code or cause a denial of service via a large width field in a BMP image. (CVE-2015-8668) Buffer overflow in the readextension function in gif2tiff.c in LibTIFF 4.0.6 allows remote attackers to cause a denial of service (application crash) via a crafted GIF file. (CVE-2016-3186) (the program gif2tiff has been obsoleted) The fpAcc function in tif_predict.c in the tiff2rgba tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted TIFF image. (CVE-2016-3622) The rgb2ycbcr tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (divide-by-zero) by setting the (1) v or (2) h parameter to 0. (CVE-2016-3623) The _TIFFVGetField function in tif_dirinfo.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image. (CVE-2016-3632) Multiple integer overflows in the (1) cvt_by_strip and (2) cvt_by_tile functions in the tiff2rgba tool in LibTIFF 4.0.6 and earlier, when -b mode is enabled, allow remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted TIFF image, which triggers an out-of-bounds write. (CVE-2016-3945) Heap-based buffer overflow in the horizontalDifference8 function in tif_pixarlog.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted TIFF image to tiffcp. (CVE-2016-3990) Heap-based buffer overflow in the loadImage function in the tiffcrop tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image with zero tiles. (CVE-2016-3991) PixarLogDecode() out-of-bound writes (CVE-2016-5314) tif_dir.c: setByteArray() Read access violation (CVE-2016-5315) tif_pixarlog.c: PixarLogCleanup() Segmentation fault (CVE-2016-5316) crash occurs when generating a thumbnail for a crafted TIFF image (CVE-2016-5317) rgb2ycbcr: command excution (CVE-2016-5320) DumpModeDecode(): Ddos (CVE-2016-5321) tiffcrop: extractContigSamplesBytes: out-of-bounds read (CVE-2016-5322) tiffcrop _TIFFFax3fillruns(): divide by zero (CVE-2016-5323) tiff: heap-based buffer overflow when using the PixarLog compression format (CVE-2016-5875) tiff: information leak in libtiff/tif_read.c (CVE-2016-6223) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7554 http://openwall.com/lists/oss-security/2015/12/26/7 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8668 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3186 https://lists.opensuse.org/opensuse-updates/2016-04/msg00064.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3622 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3623 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3632 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3945 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3990 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3991 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5314 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5315 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5316 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5317 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5320 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5321 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5322 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5323 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6223 http://openwall.com/lists/oss-security/2016/07/14/4 http://lwn.net/Vulnerabilities/695692/ https://lists.opensuse.org/opensuse-updates/2016-07/msg00087.html https://rhn.redhat.com/errata/RHSA-2016-1546.html http://lwn.net/Vulnerabilities/696207/ http://lwn.net/Vulnerabilities/698795/ http://lwn.net/Vulnerabilities/699684/ ======================== Updated packages in core/updates_testing: ======================== i586: libtiff-progs-4.0.6-1.3.mga5.i586.rpm libtiff5-4.0.6-1.3.mga5.i586.rpm libtiff-devel-4.0.6-1.3.mga5.i586.rpm libtiff-static-devel-4.0.6-1.3.mga5.i586.rpm x86_64: libtiff-progs-4.0.6-1.3.mga5.x86_64.rpm lib64tiff5-4.0.6-1.3.mga5.x86_64.rpm lib64tiff-devel-4.0.6-1.3.mga5.x86_64.rpm lib64tiff-static-devel-4.0.6-1.3.mga5.x86_64.rpm Source RPMs: libtiff-4.0.6-1.3.mga5.src.rpm
Status: NEW => ASSIGNEDHardware: i586 => AllVersion: Cauldron => 5Assignee: pkg-bugs => qa-bugsSource RPM: libtiff-4.0.6-3.mga6.src.rpm => libtiff-4.0.6-1.2.mga5.src.rpmWhiteboard: MGA5TOO => (none)
You're sure patches for all of those issues are present in this update?
(In reply to David Walser from comment #19) > You're sure patches for all of those issues are present in this update? For me, yes, all those issues are corrected
This is just the first part of what may be a very long report. Ran some tests before updating on x86_64 hardware. gif2tiff is noted as obsoleted but we still have it so can reproduce the crash as reported at https://bugzilla.suse.com/show_bug.cgi?id=973340 for CVE-2016-3186 Download the test file from https://bugzilla.redhat.com/show_bug.cgi?id=1319503. $ gif2tiff crash.gif crash.tif *** buffer overflow detected ***: gif2tiff terminated ======= Backtrace: ========= /usr/lib64/libc.so.6(+0x7238e)[0x7f6f25f5d38e] ......................... /usr/lib64/ld-2.20.so 7ffeddda6000-7ffedddc7000 rw-p 00000000 00:00 0 [stack] 7ffedddd6000-7ffedddd8000 r--p 00000000 00:00 0 [vvar] 7ffedddd8000-7ffedddda000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abort Downloaded poc.tif from https://bugzilla.suse.com/show_bug.cgi?id=984808 CVE-2016-5320 can be tested using poc.tif by following the procedure outlined at http://seclists.org/oss-sec/2016/q2/551 and involves the system command rgb2ycbcr, and gdb for analysis. $ rgb2ycbcr poc.tif out.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 464 (0x1d0) encountered. TIFFReadDirectory: Warning, Unknown field with tag 513 (0x201) encountered. TIFFReadDirectory: Warning, Unknown field with tag 642 (0x282) encountered. poc.tif: Warning, Nonstandard tile length 6, convert file. TIFFFetchNormalTag: Warning, Incompatible type for "DocumentName"; tag ignored. PixarLogDecode: Decoding error at scanline 0, incorrect header check. PixarLogDecode: Decoding error at scanline 0, invalid block type. .............................................. PixarLogDecode: Decoding error at scanline 0, invalid block type. Segmentation fault There is no chance that I am going to run a local build with debugging support turned on. $ gdb -args /usr/bin/rgb2ycbcr poc.tif tmp.tif would be the way to go. A PoC is mentioned in connection with CVE-2015-8668 at http://seclists.org/bugtraq/2015/Dec/138 but the analysis is done via ASAN (!). < $ bmp2tiff libtiff-poc.bmp out.tif > This may be the file, from http://bugzilla.maptools.org/show_bug.cgi?id=2563 $ bmp2tiff CVE-2015-8668.bmp overflow.tif Segmentation fault Continuing to search through the CVEs for PoCs. Where none are available we shall have to revert to simply testing functionality after the updates.
CC: (none) => tarazed25
Continuing... $ urpmq --whatrequires lib64tiff5 | sort | uniq indicates that a whole lot of applications depend on it including ImageMagick. $ display broken_2.tif display: Incorrect count for "Orientation"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/896. display: Translation buffer too short. `LogL16Decode' @ error/tiff.c/TIFFErrors/562. I think this is the PoC test file for CVE-2015-8781: broken_2.tif from http://bugzilla.maptools.org/show_bug.cgi?id=2522 referenced from http://seclists.org/oss-sec/2016/q1/190 $ display broken_2.tif display: Incorrect count for "Orientation"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/896. display: Translation buffer too short. `LogL16Decode' @ error/tiff.c/TIFFErrors/562. Displays a black panel. tiffinfo does not go far enough - presumably it reads just the header information. Tried combining files to force a full read: $ tiffcp broken_2.tif poc.tif combo.tif TIFFFetchNormalTag: Warning, Incorrect count for "Orientation"; tag ignored. LogL16InitState: No support for converting user data format to LogL. broken_2.tif: Error, can't read strip 0. $ tiffcp bbc2.tiff broken_2.tif test.tif _TIFFVSetField: bbc2.tiff: Invalid tag "Predictor" (not supported by codec). _TIFFVSetField: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: test.tif: Invalid tag "Predictor" (not supported by codec). _TIFFVGetField: test.tif: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: test.tif: Invalid tag "Predictor" (not supported by codec). _TIFFVGetField: test.tif: Invalid tag "BadFaxLines" (not supported by codec). TIFFFetchNormalTag: Warning, Incorrect count for "Orientation"; tag ignored. LogL16InitState: No support for converting user data format to LogL. broken_2.tif: Error, can't read strip 0. This does not tell us much because we don't know what the error report should be. From bugzilla:2522 <quote> The cause of this issue is that the attached image is of compression type "LogL" and has an invalid number of samples per pixel. My understanding is that LogL should only ever contain a single sample per pixel and thus it would make sense to detect this condition and return an error in TIFFRGBAImageOK(). </quote> $ thumbnail broken_2.tif tiny.tiff TIFFFetchNormalTag: Warning, Incorrect count for "Orientation"; tag ignored. Information on the tools available at http://www.libtiff.org/tools.html Most of the tools are probably not relevant for this CVE. For this one we need to compare the error reports after the software update. ----------------------------------------------------------------------------------- CVE-2015-8784 -> http://seclists.org/oss-sec/2016/q1/191 -> libtiff5.tif $ display libtiff5.tif display: Invalid TIFF directory; tags are not sorted in ascending order. `TIFFReadDirectoryCheckOrder' @ warning/tiff.c/TIFFWarnings/896. display: Nonstandard tile width 61, convert file. `libtiff5.tif' @ warning/tiff.c/TIFFWarnings/896. display: improper image header `libtiff5.tif' @ error/tiff.c/ReadTIFFImage/1219. "Wizard" banner image displayed. ---------------------------------------------------------------------------------- https://bugzilla.suse.com/show_bug.cgi?id=984837 -> cve-2015-5316.tif $ display cve-2016-5316.tif Abort There is a trace for this but it is not obvious that it would be useful. Also, using the hint in the above SuSE bug report: $ rgb2ycbcr cve-2016-5316.tif tmpout.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 464 (0x1d0) encountered. TIFFReadDirectory: Warning, Unknown field with tag 513 (0x201) encountered. TIFFReadDirectory: Warning, Unknown field with tag 642 (0x282) encountered. cve-2016-5316.tif: Warning, Nonstandard tile length 6, convert file. TIFFFetchNormalTag: Warning, Incompatible type for "DocumentName"; tag ignored. PixarLogDecode: Decoding error at scanline 0, incorrect header check. PixarLogDecode: Decoding error at scanline 0, invalid block type. PixarLogDecode: Decoding error at scanline 0, incorrect data check. PixarLogDecode: Decoding error at scanline 0, incorrect header check. PixarLogDecode: Decoding error at scanline 0, invalid block type. PixarLogDecode: Decoding error at scanline 0, incorrect data check. PixarLogDecode: Decoding error at scanline 0, invalid block type. PixarLogDecode: Decoding error at scanline 0, invalid distance code. PixarLogDecode: Decoding error at scanline 0, incorrect header check. PixarLogDecode: Decoding error at scanline 0, invalid block type. Segmentation fault ---------------------------------------------------------------------------------- CVE-2016-5317 https://bugzilla.suse.com/show_bug.cgi?id=984842 Ran nautilus from the command line and navigated to the QA testing directory containing the broken TIFFs and it crashed immediately with a series of messages like these: (nautilus:5671): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/lcl/qa/tiff/combo.tif: Failed to load TIFF image (nautilus:5671): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/lcl/qa/tiff/crash.gif: GIF image was truncated or incomplete. PixarLogDecode: Decoding error at scanline 0, incorrect header check. ............................. PixarLogDecode: Decoding error at scanline 0, incorrect header check. PixarLogDecode: Decoding error at scanline 0, invalid block type. This crash was predicted by the reporter. ---------------------------------------------------------------------------------- CVE-2016-5875 Some overlap here probably. http://seclists.org/oss-sec/2016/q2/629 suggests duplication of 5320 and 5314. Gonna leave this for now - need sleep. Shall sieve through the list again tomorrow.
CVE-2015-7554 http://seclists.org/fulldisclosure/2015/Dec/119 This page contains a C code extract under tag.tiff which defines an array of character data for a TIFF image file. It was not clear how this should be handled in the context of a test but it was suggested that the resultant image should be run with tiffsplit. $ tiffsplit tag.tiff Attached is the code extract and a crude ruby script to parse the file and generate the TIFF image. $ ./c2tiff.rb tag.tiff $ tiffsplit xtag.tiff TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered. Segmentation fault This tallies with some of the output from gdb as detailed in the link referenced above.
Created attachment 8504 [details] C code parser for generating tag.tiff Ruby needs to be installed. $ chmod + x c2tiff.rb $ ./c2tiff.rb tag.tiff # generates xtag.tiff - check with following command $ od -x xtag.tiff
Created attachment 8505 [details] Data relevant to CVE-2015-7554 Process this with the supplied parser: c2tiff.rb
Typo in comment 24 - should be: $ chmod +x c2tiff.rb
CVE-2016-3991 Found CVE-2016-3991.tif at http://bugzilla.maptools.org/show_bug.cgi?id=2543 but not sure how to use tiffcrop. $ tiffcrop -R 90 CVE-2016-3991.tif rot90.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 464 (0x1d0) encountered. TIFFReadDirectory: Warning, Unknown field with tag 5146 (0x141a) encountered. CVE-2016-3991.tif: Warning, Nonstandard tile length 1, convert file. TIFFReadDirectory: Warning, Unknown field with tag 26996 (0x6974) encountered. TIFFFetchNormalTag: Warning, IO error during reading of "Tag 464"; tag ignored. TIFFFetchNormalTag: Warning, ASCII value for tag "DocumentName" does not end in null byte. TIFFFetchNormalTag: Warning, IO error during reading of "Tag 5146"; tag ignored. TIFFFetchNormalTag: Warning, IO error during reading of "YResolution"; tag ignored. TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored. TIFFAdvanceDirectory: Error fetching directory count. loadImage: Image lacks Photometric interpreation tag. CVE-2016-3991.tif: Compression scheme 41 tile decoding is not implemented. CVE-2016-3991.tif: Error, can't read tile at row 0 col 1, Read 18446744073709551615 bytes of 1088. loadImage: Unable to read contiguous tiles into buffer. main: Unable to load source image. These following commands produced similar verbose output: $ tiffcrop -F horiz CVE-2016-3991.tif flip.tif $ tiffcrop -I black CVE-2016-3991.tif invert.tif
CVE-2016-3632 : http://www.openwall.com/lists/oss-security/2016/04/08/9 This mentioned TIFFVGetField.tif but gave no link to it. Tried to thumbnail a large TIFF file: $ thumbnail /home/lcl/qa/magick/PIA13706_fig1.tif fig1.tif TIFFReadDirectory: Warning, Unknown field with tag 37724 (0x935c) encountered. None of the other CVEs yielded any useful information. Where PoC files were mentioned no links were provided. Gone as far as I can with this so the next stage is installing the updates.
After the updates gif2tiff had gone, as expected. $ convert crash.gif crash.tif convert: unable to read extension block `crash.gif' @ error/gif.c/ReadGIFImage/1068. convert: no images defined `crash.tif' @ error/convert.c/ConvertImageCommand/3257. CVE-2016-3991 $ tiffcrop -R 90 CVE-2016-3991.tif rot90.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 464 (0x1d0) encountered. TIFFReadDirectory: Warning, Unknown field with tag 5146 (0x141a) encountered. CVE-2016-3991.tif: Warning, Nonstandard tile length 1, convert file. TIFFReadDirectory: Warning, Unknown field with tag 26996 (0x6974) encountered. TIFFFetchNormalTag: Warning, IO error during reading of "Tag 464"; tag ignored. TIFFFetchNormalTag: Warning, ASCII value for tag "DocumentName" does not end in null byte. TIFFFetchNormalTag: Warning, IO error during reading of "Tag 5146"; tag ignored. TIFFFetchNormalTag: Warning, IO error during reading of "YResolution"; tag ignored. TIFFFetchNormalTag: Warning, IO error during reading of "Software"; tag ignored. TIFFAdvanceDirectory: Error fetching directory count. loadImage: Image lacks Photometric interpreation tag. CVE-2016-3991.tif: Compression scheme 41 tile decoding is not implemented. CVE-2016-3991.tif: Compression scheme 41 tile decoding is not implemented. TIFFFillTile: 0: Invalid tile byte count, tile 2. CVE-2016-3991.tif: Error, can't read tile at row 0 col 2, Read 18446744073709551615 bytes of 1088. loadImage: Unable to read contiguous tiles into buffer. main: Unable to load source image. This looks exactly like the pre-update output. $ tiffcrop -R 90 bbc2.tiff rot90.tif _TIFFVSetField: bbc2.tiff: Invalid tag "Predictor" (not supported by codec). _TIFFVSetField: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: rot90.tif: Invalid tag "Predictor" (not supported by codec). _TIFFVGetField: rot90.tif: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: rot90.tif: Invalid tag "Predictor" (not supported by codec). _TIFFVGetField: rot90.tif: Invalid tag "BadFaxLines" (not supported by codec). However, the output image had been rotated 90°, so the messages must simply indicate that the image format is not quite standard. The image was originally produced from a JPEG file using IM. No errors with the following operations: $ convert bbc2.jpg bbc2.tif $ tiffcrop -R 90 bbc2.tif rot90.tif This demonstrates that IM with the updated libraries does a better job of the conversion.
CVE-2016-5316 & CVE-2016-5320 Another tool seems to have disappeared. $ rgb2ycbcr cve-2016-5316.tif tmpout.tif rgb2ycbcr: Command not found. Something to do with colourspace conversions maybe, but why has it gone? tkimg1.4 still has tiff compatibilty code for rgb2ycbcr: .....tkimg1.4/compat/libtiff/tools/rgb2ycbcr.c not that that helps us. CVE-2016-5317 Ran nautilus from a terminal and navigated to the directory containing the broken TIFFs. The file browser kept going but issued hundreds of tifflib error messages such as "TIFFFillTile: 0: Invalid tile byte count, tile 65530." and finished with "evince-thumbnailer couldn't process file: 'file:///home/lcl/qa/tiff/CVE-2016-3991.tif' Reason: Took too much time to process. (nautilus:3295): GnomeDesktop-WARNING **: Error creating thumbnail for file:///home/lcl/qa/tiff/CVE-2016-3991.tif: Failed to load RGB data from TIFF file TIFFFillTile: Read error at row 4294967295, col 4294967295, tile 0; got 0 bytes, expected 8. TIFFFillTile: 0: Invalid tile byte count, tile 1. TIFFFillTile: 0: Invalid tile byte count, tile 2. TIFFFillTile: 0: Invalid tile byte count, tile 3. NeXTDecode: Invalid data for scanline 0. TIFFFillTile: Read error at row 0, col 244, tile 5; got 0 bytes, expected 1. TIFFFillTile: 0: Invalid tile byte count, tile 6. TIFFFillTile: 0: Invalid tile byte count, tile 7. NeXTDecode: Invalid data for scanline 0. NeXTDecode: Not enough data for scanline 0. NeXTDecode: Invalid data for scanline 0. Error loading document: Invalid document" and others of that ilk. So this looks successful in that nautilus no longer crashes and reports corrupt files. The gui shows a stock thumbnail image for each of the TIFF files. ------------------------------------------------------------------------------------- CVE-2015-8781 display issues the same warning as before and shows a black rectangle. And the same here: $ tiffcp broken_2.tif bbc2.tiff combo.tif TIFFFetchNormalTag: Warning, Incorrect count for "Orientation"; tag ignored. LogL16InitState: Sorry, can not handle LogL image with Samples/pixel=59649. broken_2.tif: Error, can't read strip 0. $ thumbnail broken_2.tif tiny.tiff thumbnail: Command not found. Another missing tool. ------------------------------------------------------------------------------------- CVE-2015-7554 $ tiffsplit xtag.tiff TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered. TIFFSetField: xaaa.tif: Unknown tag 292. The second line replaces the earlier segfault, so this is good. $ ls -l xaaa.tif -rw-r--r-- 1 lcl wireshark 152 Oct 8 00:12 xaaa.tif $ tiffinfo xaaa.tif TIFF Directory at offset 0xa (10) Image Width: 1 Image Length: 1 Resolution: 0, 2.22822e+06 Bits/Sample: 8 Compression Scheme: None Rows/Strip: 8192 Planar Configuration: single image plane ------------------------------------------------------------------------------------- CVE-2015-8668 $ bmp2tiff CVE-2015-8668.bmp overflow.tif bmp2tiff: Command not found. ------------------------------------------------------------------------------------- CVE-2015-8784 $ identify libtiff5.tif identify: Invalid TIFF directory; tags are not sorted in ascending order. `TIFFReadDirectoryCheckOrder' @ warning/tiff.c/TIFFWarnings/896. identify: Nonstandard tile width 61, convert file. `libtiff5.tif' @ warning/tiff.c/TIFFWarnings/896. identify: improper image header `libtiff5.tif' @ error/tiff.c/ReadTIFFImage/1219. This is almost identical to the pre-update test with display. $ tiffinfo -d libtiff5.tif returns similar information to http://bugzilla.maptools.org/show_bug.cgi?id=2508 ------------------------------------------------------------------------------------- Random tool tests: $ tiffdump PIA13706_fig1.tif PIA13706_fig1.tif: Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 8 (0x8) next 0 (0) SubFileType (254) LONG (4) 1<0> ImageWidth (256) SHORT (3) 1<8192> ImageLength (257) SHORT (3) 1<7051> ........... Looks OK. ====== $ tiffsplit PIA13706_fig1.tif mars TIFFReadDirectory: Warning, Unknown field with tag 37724 (0x935c) encountered. _TIFFVGetField: PIA13706_fig1.tif: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: marsaaa.tif: Invalid tag "BadFaxLines" (not supported by codec). _TIFFVGetField: marsaaa.tif: Invalid tag "BadFaxLines" (not supported by codec). The output file looked identical when displayed, even to the small interactive image overlay used for panning. Expected that to be dumped to a separate file. Cannot say if the utility works properly. ====== $ tiffmedian bbc2.tif bbc_median.tif $ ls -l bbc*.tif -rw-r--r-- 1 lcl wireshark 6700 Oct 7 22:58 bbc2.tif -rw-r--r-- 1 lcl wireshark 3874 Oct 8 00:52 bbc_median.tif The palette file generated displays a white rectangle with some black pixels. Not going to question this. ====== $ tiff2ps bbc2.tiff > bbc2.ps _TIFFVSetField: bbc2.tiff: Invalid tag "Predictor" (not supported by codec). _TIFFVSetField: bbc2.tiff: Invalid tag "BadFaxLines" (not supported by codec). $ gs bbc2.ps This displays a white sheet with the BBC2 icon in the bottom lefthand corner. ====== $ tiff2bw xplns.tiff greyscale.tif That generated an image of the Pleiades in grey scale. The original contained blues and black. $ tiffcmp xplns.tiff greyscale.tif Compression: 8 1 ====== Through all these after-update checks IM display has worked fine. It copes with a very large TIFF: $ identify PIA13706_fig1.tif PIA13706_fig1.tif TIFF 8192x7051 8192x7051+0+0 8-bit sRGB 13.62MB 0.000u 0:00.000 $ convert -resize 20% -quality 100 PIA13706_fig1.tif MarsCrater.jpg Copied marsaaa.tif to another file and shrank it in place. $ mogrify -resize 20% -quality 100 SantaMaria.tif $ tiffinfo SantaMaria.tif _TIFFVSetField: SantaMaria.tif: Invalid tag "BadFaxLines" (not supported by codec). TIFF Directory at offset 0x1e1348 (1971016) Image Width: 1638 Image Length: 1410 Resolution: 495.062, 495.062 pixels/inch Bits/Sample: 8 Compression Scheme: LZW .............
Addendum: the thumbnailer in nautilus displays proper icons for most of the "good" TIFFs and a couple of the PoC images.
In VirtualBox, M5, KDE, 32-bit In VirtualBox and KDE Test files: pic1.bmp pic2.bmp Packages under test: libtiff5 libtiff-progs [root@localhost wilcal]# urpmi libtiff5 Package libtiff5-4.0.6-1.2.mga5.i586 is already installed [root@localhost wilcal]# urpmi libtiff-progs Package libtiff-progs-4.0.6-1.2.mga5.i586 is already installed bmp2tiff pic1.bmp pic1.tif works tiff2pdf pic1.tif > pic1.pdf works [wilcal@localhost tiff]$ tiffinfo pic1.tif TIFF Directory at offset 0xee13e (975166) Image Width: 640 Image Length: 504 Bits/Sample: 8 Compression Scheme: PackBits Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 4 Planar Configuration: single image plane pic1.tif opens successfully with Gimp tiffinfo -d pic1.tif > testinfo1.txt ( generates a mountain of info ) Install libtiff5 & libtiff-progs from core updates_testing [root@localhost wilcal]# urpmi libtiff5 Package libtiff5-4.0.6-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi libtiff-progs Package libtiff-progs-4.0.6-1.3.mga5.i586 is already installed [wilcal@localhost tiff]$ bmp2tiff pic2.bmp pic2.tif bash: bmp2tiff: command not found tiff2pdf pic1.tif > pic2.pdf works [wilcal@localhost tiff]$ tiffinfo pic1.tif TIFF Directory at offset 0xee13e (975166) Image Width: 640 Image Length: 504 Bits/Sample: 8 Compression Scheme: PackBits Photometric Interpretation: RGB color Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 4 Planar Configuration: single image plane tiffinfo -d pic1.tif > testinfo2.txt ( generates a mountain of info ) What happened to the bmp2tiff command?
CC: (none) => wilcal.int
(In reply to William Kenney from comment #32) > What happened to the bmp2tiff command? Upstream decided to remove some programs: bmp2tiff, gif2tiff, ras2tiff, rgb2ycbcr and thumbnail (bmp2tiff, gif2tiff and ras2tiff are moved into an archive directory and are not compiled ; rgb2ycbcr and thumbnail are compiled only for the internal tests suite but not provided).
(In reply to Nicolas Salguero from comment #33) > Upstream decided to remove some programs: bmp2tiff, gif2tiff, ras2tiff, > rgb2ycbcr and thumbnail (bmp2tiff, gif2tiff and ras2tiff are moved into an > archive directory and are not compiled ; rgb2ycbcr and thumbnail are > compiled only for the internal tests suite but not provided). Where can I find the official documentation as to what programs are provided?
I found that page: http://www.simplesystems.org/libtiff/tools.html (but rgb2ycbcr and thumbnail are referenced so I am not sure if it is up to the date).
(In reply to Nicolas Salguero from comment #35) > I found that page: http://www.simplesystems.org/libtiff/tools.html (but > rgb2ycbcr and thumbnail are referenced so I am not sure if it is up to the > date). Many thanks. I'll get back to this shortly.
OK Nicolas. After spending considerable time with this I'm gonna toss it back to you. Using: http://www.simplesystems.org/libtiff/tools.html And given two starting files: pic1.jpg pic2.jpg Give me a handful of commands ( with the exact syntax ) that you expect to work. For me some of these commands do not work or do not work as outlined on the page you supplied. This is a security update not an operational bug test. So all we have to do here is to make ourselves comfortable that the update was successful.
(In reply to William Kenney from comment #37) > Give me a handful of commands ( with the exact syntax ) that you expect to > work. I am sorry, I never used the programs provided by libtiff-progs so I do not know the syntax for each program. When you say that some of these commands do not work as described, does it mean that the associated man pages are not up to date also?
(In reply to Nicolas Salguero from comment #38) > I am sorry, I never used the programs provided by libtiff-progs so I do not > know the syntax for each program. When you say that some of these commands > do not work as described, does it mean that the associated man pages are not > up to date also? Example: rgb2ycbcr I tried to convert an rgb to a tif file using this command and got a command not found result. So which ones work and which ones don't? Yes, I believe that your referenced page is either inaccurate or not up to date. Or I don't understand something.
(In reply to William Kenney from comment #39) > Example: rgb2ycbcr That program is one of the five that are not provided anymore (the other ones are bmp2tiff, gif2tiff, ras2tiff and thumbnail).
Thanks
CC: (none) => mageiaWhiteboard: (none) => advisory
Given that wilcal has demonstrated that the library can be used successfully in normal image operations, how do we assess this bug? CVEs *6-5317 and *5-7554 have been addressed, other tests are equivocal, and most of the CVEs cannot be tested at present (for lack of information upstream) should it be put on hold?
With CVEs, we test what we can test. You've already gone above and beyond what I expected. Unless you have found with a PoC that some issue isn't fixed, then you can OK it.
I share that I was going to bring this bug up at our weekly QA meeting. #1 It's a security, not a functional bug #2 It updates cleanly. I kinda gave up on it yesterday when I found that some commands worked in the 32-bit version but not the 64-bit version. I'm kinda leaning towards letting this move on and let someone else create a bug that contains the functional problems.
LWN reference for CVE-2016-3622: http://lwn.net/Vulnerabilities/703467/ openSUSE has issued advisories for some of these CVEs today (October 13): https://lists.opensuse.org/opensuse-updates/2016-10/msg00048.html https://lists.opensuse.org/opensuse-updates/2016-10/msg00049.html
Upstream has committed some fixes in tools tiff2pdf and tiffcp (2016-10-08 and 2016-10-09). There are 4 new security problems corrected and one of those issues is CVE-2016-5652. I will push a new version of the packages.
Suggested advisory: ======================== The updated packages fix security vulnerabilities: The _TIFFVGetField function in tif_dir.c in libtiff 4.0.6 allows attackers to cause a denial of service (invalid memory write and crash) or possibly have unspecified other impact via crafted field data in an extension tag in a TIFF image. (CVE-2015-7554) Heap-based buffer overflow in the PackBitsPreEncode function in tif_packbits.c in bmp2tiff in libtiff 4.0.6 and earlier allows remote attackers to execute arbitrary code or cause a denial of service via a large width field in a BMP image. (CVE-2015-8668) Buffer overflow in the readextension function in gif2tiff.c in LibTIFF 4.0.6 allows remote attackers to cause a denial of service (application crash) via a crafted GIF file. (CVE-2016-3186) (the program gif2tiff has been obsoleted) The fpAcc function in tif_predict.c in the tiff2rgba tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted TIFF image. (CVE-2016-3622) The rgb2ycbcr tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (divide-by-zero) by setting the (1) v or (2) h parameter to 0. (CVE-2016-3623) The _TIFFVGetField function in tif_dirinfo.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image. (CVE-2016-3632) Multiple integer overflows in the (1) cvt_by_strip and (2) cvt_by_tile functions in the tiff2rgba tool in LibTIFF 4.0.6 and earlier, when -b mode is enabled, allow remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted TIFF image, which triggers an out-of-bounds write. (CVE-2016-3945) Heap-based buffer overflow in the horizontalDifference8 function in tif_pixarlog.c in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (crash) or execute arbitrary code via a crafted TIFF image to tiffcp. (CVE-2016-3990) Heap-based buffer overflow in the loadImage function in the tiffcrop tool in LibTIFF 4.0.6 and earlier allows remote attackers to cause a denial of service (out-of-bounds write) or execute arbitrary code via a crafted TIFF image with zero tiles. (CVE-2016-3991) PixarLogDecode() out-of-bound writes (CVE-2016-5314) tif_dir.c: setByteArray() Read access violation (CVE-2016-5315) tif_pixarlog.c: PixarLogCleanup() Segmentation fault (CVE-2016-5316) crash occurs when generating a thumbnail for a crafted TIFF image (CVE-2016-5317) rgb2ycbcr: command excution (CVE-2016-5320) DumpModeDecode(): Ddos (CVE-2016-5321) tiffcrop: extractContigSamplesBytes: out-of-bounds read (CVE-2016-5322) tiffcrop _TIFFFax3fillruns(): divide by zero (CVE-2016-5323) tiff: heap-based buffer overflow when using the PixarLog compression format (CVE-2016-5875) tiff: information leak in libtiff/tif_read.c (CVE-2016-6223) tiff2pdf: fix write buffer overflow of 2 bytes on JPEG compressed images (CVE-2016-5652) tiffcp: fix out-of-bounds write on tiled images with odd tile width vs image width tiff2pdf: fix read -largely- outsize of buffer in t2p_readwrite_pdf_image_tile(), causing crash, when reading a JPEG compressed image with TIFFTAG_JPEGTABLES length being one. tiffcp: fix read of undefined variable in case of missing required tags tiffcrop: fix read of undefined buffer in readContigStripsIntoBuffer() due to uint16 overflow References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7554 http://openwall.com/lists/oss-security/2015/12/26/7 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8668 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3186 https://lists.opensuse.org/opensuse-updates/2016-04/msg00064.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3622 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3623 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3632 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3945 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3990 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3991 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5314 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5315 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5316 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5317 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5320 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5321 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5322 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5323 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5875 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6223 http://openwall.com/lists/oss-security/2016/07/14/4 http://lwn.net/Vulnerabilities/695692/ https://lists.opensuse.org/opensuse-updates/2016-07/msg00087.html https://rhn.redhat.com/errata/RHSA-2016-1546.html http://lwn.net/Vulnerabilities/696207/ http://lwn.net/Vulnerabilities/698795/ http://lwn.net/Vulnerabilities/699684/ http://lwn.net/Vulnerabilities/703467/ https://lists.opensuse.org/opensuse-updates/2016-10/msg00048.html https://lists.opensuse.org/opensuse-updates/2016-10/msg00049.html https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5652 ======================== Updated packages in core/updates_testing: ======================== i586: libtiff-progs-4.0.6-1.4.mga5.i586.rpm libtiff5-4.0.6-1.4.mga5.i586.rpm libtiff-devel-4.0.6-1.4.mga5.i586.rpm libtiff-static-devel-4.0.6-1.4.mga5.i586.rpm x86_64: libtiff-progs-4.0.6-1.4.mga5.x86_64.rpm lib64tiff5-4.0.6-1.4.mga5.x86_64.rpm lib64tiff-devel-4.0.6-1.4.mga5.x86_64.rpm lib64tiff-static-devel-4.0.6-1.4.mga5.x86_64.rpm Source RPMs: libtiff-4.0.6-1.4.mga5.src.rpm
Will test M5-64 I will have a go at this later today: - pillaging Len's heroic work - ignoring anything to do with the abandoned programs Comment 33. These are the programs provided by the original package libtiff-progs (** = the ones abandoned by this update): /usr/bin/bmp2tiff** â/usr/bin/fax2ps â/usr/bin/fax2tiff â/usr/bin/gif2tiff** â/usr/bin/pal2rgb â/usr/bin/ppm2tiff â/usr/bin/ras2tiff** â/usr/bin/raw2tiff â/usr/bin/rgb2ycbcr** â/usr/bin/thumbnail** â/usr/bin/tiff2bw â/usr/bin/tiff2pdf â/usr/bin/tiff2ps â/usr/bin/tiff2rgba â/usr/bin/tiffcmp â/usr/bin/tiffcp â/usr/bin/tiffcrop â/usr/bin/tiffdither â/usr/bin/tiffdump â/usr/bin/tiffgt â/usr/bin/tiffinfo â/usr/bin/tiffmedian â/usr/bin/tiffset â/usr/bin/tiffsplit
CC: (none) => lewyssmith
Testing Mageia 5 x64 real H/W I only tested AFTER the update, and not those POCs for obsoleted commands. After looking at Len's earlier work, it seemed that the various corrections are not generally evident against the POCs - which I tried anyway. lib64tiff5-4.0.6-1.4.mga5 libtiff-progs-4.0.6-1.4.mga5 POCs ---- broken_2.tif [http://bugzilla.maptools.org/show_bug.cgi?id=2522] $ display broken_2.tif [black window/image] The next 4 POCs are from http://www.openwall.com/lists/oss-security/2015/01/24/16 $ display libtiff-mem2.tif [Long blue/green image] $ display libtiff-cvs-1.tif [0 size display window, no image] $ display libtiff-cvs-2.tif [ImageMagick logo] $ display libtiff5.tif [ImageMagick logo] cve-2016-5316.tif [https://bugzilla.suse.com/show_bug.cgi?id=984837, link 'rep'] $ display cve-2016-5316.tif [Tiny narrow black window/image] tag.tiff from Comments 23-26, attachments 8504-5 $ tiffsplit xtag.tiff [No output] TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered. TIFFSetField: xaaa.tif: Unknown tag 292. $ display xtag.tiff [ImageMagick logo] cve-2016-3991.tif [http://bugzilla.maptools.org/show_bug.cgi?id=2543 attachment] $ display cve-2016-3991.tif [ImageMagick logo] All produced errors, sometimes copious; but no crash. For update purposes, this is OK because they are all malformed files. =========================================== Programs ------- To start with, a good source of PPM images: http://www.cs.cornell.edu/courses/cs664/2003fa/images/project2/part2/part2pairs.zip of which I used just a few. All the following tests were done with 'good' images; flawed POC ones produced errors. To test ppm2tiff & supply some TIFFs to play with: $ ppm2tiff cayuga_1.ppm cayuga.tif $ display cayuga.tif etc for falls, mcfaddin, sage, start The resulting TIFFs were fine, no errors en route. $ tiff2bw cayuga.tif cayugaBW.tif $ display cayugaBW.tif for several source images. Result correct B&W images, no errors. $ tiff2pdf cayuga.tif > cayuga.pdf The PDF result was tiny, but otherwise correct; no errors. $ tiff2ps falls.tif > falls.ps The PostScript result, large, viewed correctly. $ tiff2rgba sage.tif sageRGBA.tif $ display sageRGBA.tif The result looked the same as the original, but the file is bigger. $ tiffcmp start.tif startBW.tif SamplesPerPixel: 3 1 Compared the original and B&W versions of the same image. No errors. $ tiffcp cayuga.tif ElderChmpgn.tiff start.tif concat.tif $ display concat.tif This command is supposed to join several input images into one. However, viewing the result shows *only the first*. I thought this was an error, but apparently one TIFF file can contain several indpendant images - beyond the ken of viewers; so I think this is OK. See 'tiffsplit' later. $ tiffcrop -m 100,100,100,100 -R 90 ElderChmpgn.tiff EFCcropped.tif $ display EFCcropped.tif The reult was as it should be: trimmed by 100 [pixels?] on all sides & rotated 90deg. $ tiffdump xtag.tiff outputs sensible looking information. $ tiffinfo xtag.tiff likewise. $ tiffmedian sage.tif sageMED.tif $ display sageMED.tif The ouptut file is slightly posterised, with a reduced colour palate. $ tiffsplit concat.tif $ ls concat.tif xaaa.tif xaab.tif xaac.tif This command splits a multiple-image TIFF file into individual sequentially named image files. The source was that created by 'tiffcp' earlier; the 3 output images are correct. ----------- So given that all manipulations with the library commands gave correct results with sane TIFF images; and errors were only associated with malformed ones, this update looks good. OK'ing it.
Whiteboard: advisory => advisory MGA5-64-OK
@lewis re comment 49 > After looking at Len's earlier work, it seemed that the various corrections are not generally evident against the POCs - which I tried anyway. Good, tidy work Lewis. Have to agree that some of the PoC tests are equivocal. Not a lot more we can do about the CVEs.
Test result omitted from Comment 49 --------------------------------- $ tiffgt cayuga.tif ElderChmpgn.tiff fallsBW.tif The man page says "tiffgt displays one or more [TIFF] images. Each image is placed in a fixed size window..." This displayed just the *first* image; I could not raise subsequent ones. Is this analagous to the case of 'tiffcp', where several images are contained in the same TIFF file? It would be useful to try this *before* the update... However, 'tiffgt' seems a preferable test (to ImageMagick 'display') for displaying a single image using this library. POCs re-visited --------------- Additional testing M5-64 with the POC files (because I think now that simple use of ImageMagick 'display' may not actually involve this library). $ tiffinfo broken_2.tif Warning, then sensible O/P $ tiffdump broken_2.tif Sensible O/P, no complaints $ tiffinfo libtiff-mem2.tif Warnings, the info, errors $ tiffdump libtiff-mem2.tif Sensible O/P, then error $ tiffinfo libtiff-cvs-1.tif Several warnings, info, errors $ tiffdump libtiff-cvs-1.tif Sensible O/P with 1 embedded complaint $ tiffinfo libtiff-cvs-2.tif Warnings, the info, errors $ tiffdump libtiff-cvs-2.tif Sensible O/P, then error $ tiffinfo libtiff5.tif Warnings, the info, errors $ tiffdump libtiff5.tif Sensible O/P, then error $ tiffinfo cve-2016-5316.tif Many warnings, the info, errors $ tiffdump cve-2016-5316.tif Good O/P, then error $ tiffinfo xtag.tiff Good O/P, no complaints $ tiffdump xtag.tiff Good O/P, no complaints $ tiffinfo CVE-2016-3991.tif Many warnings, the O/P with bad DocName, errors $ tiffdump CVE-2016-3991.tif Sensible dump, error at end The only thing illustrated by these tests is the absence of nasty behaviour like a crash. The update OK is legitimised. Should we validate it without 32-bit OK?
Well, I could try this in a 32bit vbox, but not before this evening.
Starting the 32bit tests.
Comment on attachment 8505 [details] Data relevant to CVE-2015-7554 This should have been the original source code. Including it here: unsigned char tiff[] = { /* little-endian */ 0x49, 0x49, /* version */ 0x2a, 0x00, /* tif->tif_diroff */ 0x09, 0x00, 0x00, 0x00, 0x00, /* tag count */ 0x07, 0x00, /* tag | type | count | offset/value */ /* TIFFTAG_IMAGEWIDTH */ 0x00, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_IMAGELENGTH */ 0x01, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_BITSPERSAMPLE */ 0x02, 0x01, 0x03, 0x00, 0x03, 0x00, 0x00, 0x00, 0x63, 0x00, 0x00, 0x00, /* TIFFTAG_STRIPOFFSETS */ 0x11, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_STRIPBYTECOUNTS */ 0x17, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_YRESOLUTION */ 0x1b, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x22, 0x00, /* TIFFTAG_GROUP3OPTIONS */ 0x24, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x41, 0x41, 0x41, 0x41, /* tif->tif_nextdiroff */ 0x00, 0x00, 0x00, 0x00, /* bits per sample */ 0x08, 0x00, 0x08, 0x00, 0x08, 0x00, };
Comment on attachment 8505 [details] Data relevant to CVE-2015-7554 /* This should have been the original code, not the image */ unsigned char tiff[] = { /* little-endian */ 0x49, 0x49, /* version */ 0x2a, 0x00, /* tif->tif_diroff */ 0x09, 0x00, 0x00, 0x00, 0x00, /* tag count */ 0x07, 0x00, /* tag | type | count | offset/value */ /* TIFFTAG_IMAGEWIDTH */ 0x00, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_IMAGELENGTH */ 0x01, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_BITSPERSAMPLE */ 0x02, 0x01, 0x03, 0x00, 0x03, 0x00, 0x00, 0x00, 0x63, 0x00, 0x00, 0x00, /* TIFFTAG_STRIPOFFSETS */ 0x11, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_STRIPBYTECOUNTS */ 0x17, 0x01, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, /* TIFFTAG_YRESOLUTION */ 0x1b, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x22, 0x00, /* TIFFTAG_GROUP3OPTIONS */ 0x24, 0x01, 0x04, 0x00, 0x01, 0x00, 0x00, 0x00, 0x41, 0x41, 0x41, 0x41, /* tif->tif_nextdiroff */ 0x00, 0x00, 0x00, 0x00, /* bits per sample */ 0x08, 0x00, 0x08, 0x00, 0x08, 0x00, };
Summary; * some sort of test, ? no back-trail, notes echo suggestions upstream. 7554 * 8668 * 8781 * 8784 * 3186 * 3622 tiff2rgba (tiff2rgba_1.tif) 3623 rgb2ycbcr (rgb2ycbcr_cvtRaster.tif) 3632 thumbnail (TIFFVGetField.tif) 3945 tiff2rgba 3990 tiffcp 3991 * 5314 ? 5315 ? 5316 ? 5317 * thumbnail, nautilus 5320 * 5321 ? 5322 ? 5323 ? 5652 ? 5875 ? 6223 ? 22, plus 4 without CVEs ------------------------------------------------------------------------------- [CVE-2015-7554] $ tiffsplit xtag.tiff TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered. Segmentation fault ------------------------------------------------------------------------------- [CVE-2015-8668] $ bmp2tiff CVE-2015-8668.bmp overflow.tif Segmentation fault # After updates: ------------------------------------------------------------------------------- [CVE-2015-8781] $ display broken_2.tif display: Incorrect count for "Orientation"; tag ignored. `TIFFFetchNormalTag' @ warning/tiff.c/TIFFWarnings/896. display: Translation buffer too short. `LogL16Decode' @ error/tiff.c/TIFFErrors/562. # Displays a black panel $ tiffinfo broken_2.tif TIFFFetchNormalTag: Warning, Incorrect count for "Orientation"; tag ignored. TIFF Directory at offset 0x11866 (71782) $ tiffgt broken_2.tif Displays a black panel. # No output, which seems odd. Perhaps the tiffinfo code has been patched into IM. To address any doubt about IM, running strace on the display command shows that ImageMagick is using the libtiff library; looks like it searches for it. $ strace display broken_2.tif >& trace $ cat trace | grep libtiff open("/usr/lib64/libtiff.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/libtiff.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/sse2/libtiff.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/libtiff.so.5", O_RDONLY|O_CLOEXEC) = 4 ------------------------------------------------------------------------------- [CVE-2015-8784] Before updates: $ tiffinfo -d libtiff5.tif generates the same output as shown at http://bugzilla.maptools.org/show_bug.cgi?id=2508 Following the thread indicates that this is for CVE-2015-8784. ------------------------------------------------------------------------------- [CVE-2016-3186] $ gif2tiff crash.gif crash.tif # before >>> *** buffer overflow detected ***: gif2tiff terminated ======= Backtrace: ========= /usr/lib/i686/libc.so.6(+0x69dc9)[0xb75a7dc9] .... ------------------------------------------------------------------------------- [CVE-2016-3991] Following comment 49, $ tiffcrop -m 50,50,50,50 CVE-2016-3991.tif cropped.tif # As expected this segfaulted after several lines of error information. ------------------------------------------------------------------------------- [CVE-2016-5317] nautilus aborted on the directory containing the PoC files. Moved the overflow.tif file out of the way because that was causing a stream of errors. ------------------------------------------------------------------------------- [CVE-2016-5320] $ rgb2ycbcr poc.tif out.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 464 (0x1d0) encountered. ------------------------------------------------------------------------------ Continuing with this later. After the updates some of these few tests will have to be skipped.
Updated the four packages and the ghostscript stuff. As far as possible tried the earlier PoC tests. _____________________________________________________________________________ CVE-2015-7554: Same messages, no segfault -> good _____________________________________________________________________________ CVE-2015-8668: $ convert CVE-2015-8668.bmp bmpoflo.tif convert: length and filesize do not match `CVE-2015-8668.bmp' @ error/bmp.c/ReadBMPImage/813. convert: unrecognized bits per pixel `CVE-2015-8668.bmp' @ error/bmp.c/ReadBMPImage/834. convert: no images defined `bmpoflo.tif' @ error/convert.c/ConvertImageCommand/3257. No segfault so this is probably good. _____________________________________________________________________________ CVE-2015-8781: tiffgt displays black panel, tiffinfo as before -> no change _____________________________________________________________________________ CVE-2015-8784: Similar information without backtrace or abort -> good _____________________________________________________________________________ CVE-2016-3186: No gif2tiff $ convert crash.gif crash.tif convert: unable to read extension block `crash.gif' @ error/gif.c/ReadGIFImage/1068. convert: no images defined `crash.tif' @ error/convert.c/ConvertImageCommand/3257. A trace of this command confirms that tifflib is not used. Patch unconfirmed. _____________________________________________________________________________ CVE-2016-3991: fault analysis -> "Unable to load source image" -> good _____________________________________________________________________________ CVE-2016-5317: nautilus stayed up, blank rectangles for bad tiffs -> good _____________________________________________________________________________ CVE-2016-5320: No more rgb2ycbcr. tiffinfo echoes original output -> good? _____________________________________________________________________________ Isolated tiff files with extracts from tiffinfo output: $ tiffinfo libtiff-cvs-1.tif # Photometric Interpretation: YCbCr # YCbCr Subsampling: 2, 1 $ tiffinfo libtiff-cvs-2.tif # Compression Scheme: NeXT $ tiffinfo libtiff-mem2.tif # Compression Scheme: LZW # Photometric Interpretation: CIE L*a*b* _____________________________________________________________________________ Downloaded the image pack from the link referenced in comment 49. Thanks Lewis. Generated TIFF files from the new PPMs a la $ ppm2tiff cayuga_1.ppm cayuga.tif Viewed them with tiffgt; all fine. $ tiff2bw sage_1.tif sage_1_greyscale.tif $ display sage_1_greyscale.tif $ tiff2ps falls_2.tif > falls.ps $ display falls.ps $ gs falls.ps display rendered it as is but gs displayed a narrower image, possibly because it is predisposed to squeeze images into A4 dimensions, by default. $ tiff2pdf cayuga_2.tif > cayuga.pdf Lewis saw this. display showed an image reduced almost to a thumbnail. okular showed it full size. $ tiff2rgba mcfaddin_1.tif mcfaddin_rgba.tif The result file looked identical and identify and tiffinfo confirmed 800x600 for both. $ tiffcmp sage_1.tif sage_1_greyscale.tif SamplesPerPixel: 3 1 Looks OK. $ tiffcp cayuga.tif sage_1.tif mcfaddin_rgba.tif concat.tif tiffinfo shows three directory sections for 800x600 images. $ display concat.tif This shows the first image and a right click on the image brings up the menu where you select next to see the next image. The window title changes to "concat.tif[scene:1 frames:3]". Presumably the first frame is numbered 0. $ tiffcrop -m 40,40,40,40 -R 180 sage_1.tif cropped.tif This works as Lewis said. This time an inverted image with the borders trimmed a little. $ tiffmedian sage_1.tif sage_median.tif The colours look quantized aka posterized. Did not get very far with the options - all came back with help text. That could be a bug, or options might no longer be supported. $ tiffsplit concat.tif Generated xaa{a,b,c}.tif. These three files looked identical to the originals. So these tests confirm the 64bit results. We are probably all agreed that this bug should be cleared.
Whiteboard: advisory MGA5-64-OK => advisory MGA5-64-OK MGA5-32-OK
Validating. Advisory already uploaded.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0349.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED