Fedora has issued an advisory on November 24: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/T7WN6B6ICKF57D6HQJVWPQYDNBPP2VY6/ The issue is fixed upstream in 4.0.10. The other CVE was patched in Bug 23788.
Debian has issued an advisory on November 30: https://www.debian.org/security/2018/dsa-4349 It includes this CVE and another one we haven't listed before.
Summary: libtiff new security issue CVE-2018-18557 => libtiff new security issues CVE-2018-15209 and CVE-2018-18557
openSUSE has issued an advisory on November 30: https://lists.opensuse.org/opensuse-updates/2018-11/msg00138.html It adds another CVE we haven't listed before.
Summary: libtiff new security issues CVE-2018-15209 and CVE-2018-18557 => libtiff new security issues CVE-2018-12900, CVE-2018-15209, and CVE-2018-18557
openSUSE has issued an advisory on December 8: https://lists.opensuse.org/opensuse-updates/2018-12/msg00038.html It adds another CVE we haven't listed before.
Summary: libtiff new security issues CVE-2018-12900, CVE-2018-15209, and CVE-2018-18557 => libtiff new security issues CVE-2018-12900, CVE-2018-15209, CVE-2018-18557, CVE-2018-19210
CVE-2018-15209 has the same fix as CVE-2017-11613. Suggested advisory: ======================== The updated packages fix security vulnerabilities: Heap-based buffer overflow in the cpSeparateBufToContigBuf function in tiffcp.c in LibTIFF 4.0.9 allows remote attackers to cause a denial of service (crash) or possibly have unspecified other impact via a crafted TIFF file. (CVE-2018-12900) LibTIFF 4.0.9 (with JBIG enabled) decodes arbitrarily-sized JBIG into a buffer, ignoring the buffer size, which leads to a tif_jbig.c JBIGDecode out-of-bounds write. (CVE-2018-18557) In LibTIFF 4.0.9, there is a NULL pointer dereference in the TIFFWriteDirectorySec function in tif_dirwrite.c that will lead to a denial of service attack, as demonstrated by tiffset. (CVE-2018-19210) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12900 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-18557 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19210 https://www.debian.org/security/2018/dsa-4349 https://lists.opensuse.org/opensuse-updates/2018-11/msg00138.html https://lists.opensuse.org/opensuse-updates/2018-12/msg00038.html ======================== Updated packages in core/updates_testing: ======================== libtiff-progs-4.0.9-1.9.mga6 lib(64)tiff5-4.0.9-1.9.mga6 lib(64)tiff-devel-4.0.9-1.9.mga6 lib(64)tiff-static-devel-4.0.9-1.9.mga6 from SRPMS: libtiff-4.0.9-1.9.mga6.src.rpm
CVE: (none) => CVE-2018-12900, CVE-2018-18557, CVE-2018-19210Assignee: nicolas.salguero => qa-bugsStatus: NEW => ASSIGNED
CVE-2018-12900 PoC at http://bugzilla.maptools.org/attachment.cgi?id=862 to use: $ tiffcp -i poc1|2 result.tif Will attach the two unrar'd test files. CVE-2018-18557 PoC at https://www.exploit-db.com/exploits/45694 details a sizeable C program to produce test cases (we can avoid this path). Also at the page end "An example TIFF file that crashes various tiff readers". In character hex, and I am puzzling how to convert it to real binary. CVE-2018-19210 PoC at http://bugzilla.maptools.org/attachment.cgi?id=873 to trigger: $ tiffset poc0 Will attach the unrar'd test file. You will need libtiff-progs as well as the library lib64tiff5. -------------------------------------------------------------- M6/x64 BEFORE update: libtiff-progs-4.0.9-1.8.mga6, lib64tiff5-4.0.9-1.8.mga6 $ tiffcp -i 12900poc1 result.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. 12900poc1: Warning, Nonstandard tile width 32769, convert file. TIFFFetchStripThing: Warning, Incorrect count for "StripOffsets"; tag ignored. TIFFFetchStripThing: Warning, Incorrect count for "StripByteCounts"; tag ignored. TIFFReadDirectory: Warning, Ignoring ColorMap since BitsPerSample tag not found. JPEGFixupTagsSubsampling: Warning, Unable to auto-correct subsampling values, likely corrupt JPEG compressed data in first strip/tile; auto-correcting skipped. JPEGLib: Not a JPEG file: starts with 0x80 0x3f. TIFFFillTile: 0: Invalid tile byte count, tile 1. TIFFFillTile: 0: Invalid tile byte count, tile 2. TIFFFillTile: 0: Invalid tile byte count, tile 3. JPEGSetupEncode: BitsPerSample 1 not allowed for JPEG. result.tif: Error, can't write tile at 0 0. [unsure about this] $ tiffcp -i 12900poc2 result.tif TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. 12900poc2: Warning, Nonstandard tile length 1, convert file. TIFFFetchStripThing: Warning, Incorrect count for "StripOffsets"; tag ignored. TIFFFetchStripThing: Warning, Incorrect count for "StripByteCounts"; tag ignored. TIFFReadDirectory: Warning, Ignoring ColorMap because BitsPerSample=32776>24. TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.. 12900poc2: Warning, using bottom-left orientation. DumpModeDecode: Not enough data for scanline 0, expected a request for at most 152 bytes, got a request for 4195328 bytes. Segmentation fault (core dumped) [good] $ tiffset 19210poc0 TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not sorted in ascending order. TIFFReadDirectory: Warning, Unknown field with tag 390 (0x186) encountered. TIFFReadDirectory: Warning, Unknown field with tag 302 (0x12e) encountered. TIFFReadDirectory: Warning, Unknown field with tag 61961 (0xf209) encountered. TIFFReadDirectory: Warning, Photometric tag is missing, assuming data is YCbCr. TIFFReadDirectory: Warning, SamplesPerPixel tag is missing, applying correct SamplesPerPixel value of 3. Segmentation fault (core dumped) [good] To pursue tomorrow. If somebody can point to converting that character hex representation file to binary, please say so.
CC: (none) => lewyssmith
Created attachment 10617 [details] Test file for CVE 19210 From http://bugzilla.maptools.org/attachment.cgi?id=873 Use: $ tiffset poc0
Created attachment 10618 [details] Test file 1/2 for CVE 12900 From http://bugzilla.maptools.org/attachment.cgi?id=862 Use: $ tiffcp -i <filename> result.tif -------------------------------------- Typo in previous example c6, use = $ tiffset <filename>
Created attachment 10619 [details] Test file 2/2 for CVE 12900 From http://bugzilla.maptools.org/attachment.cgi?id=862 Use: $ tiffcp -i <filename> result.tif
M6/64 AFTER update to: - lib64tiff5-4.0.9-1.9.mga6.x86_64 - libtiff-progs-4.0.9-1.9.mga6.x86_64 $ tiffcp -i 12900poc1 result.tif Alas, result identical to previously in c5. $ tiffcp -i 12900poc2 result.tif [O/P identical to here... 12900poc2: Warning, using bottom-left orientation. 12900poc2: Error, either TileWidth (4195328) or BitsPerSample (32776) is too large. re c5, NO segfault, update OK. $ tiffset 19210poc0 19210poc0: Failed to allocate memory for to read TIFF directory (0 elements of 12 bytes each). TIFFReadDirectory: Failed to read directory at offset 5356. Now this looks good (NO segfault) cf c5; except having re-run this test *before* the update, the result was as here, and no segfault as yesterday. Unconvincing. ------------- In all, of 4 potential tests: 1 unchanged, 1 OK, 1 uncertain, 1 yet to try (the hex file for want of "how?'), I hesitate to OK this update hoping that, given that things are set up here to speedily test 2/3 of the CVEs, somebody can do better.
MGA6-32 MATE on IBM Thinkpad R50e No installation issues. Tried some commands with a set of own tif files of different origins (digital camera or scanner or converted from jpg wih GIMP. No succes at all with commands tiff2bw or tiff2pdf. Examples from CLI: $ tiff2bw 001.tif 001bw.tif 001.tif: Bad samples/pixel 4. $ tiff2pdf 001.tif %PDF-1.1 %���� 1 0 obj << /Type /Catalog /Pages 3 0 R >> endobj 2 0 obj << /CreationDate (D:20181228094800) /ModDate (D:20181228094800) /Producer (libtiff / tiff2pdf - 20171118) /Title (/video/vakanties/dias bermuda 2003/001.tif) /Subject (Created with The GIMP) and more ...... What seems OK: $ tiff2rgba 001.tif 001rgba.tiff produces a picture that seems OK viewed with gwenview. $ tiffdither rietkleur003.tif rikldit003.tif TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.. tiffdither: Not a b&w image. OK, it is a color image, decent message to me. $ tiffdither gray1.tif gray1dit.tif produces a heavily dithered image. Seems OK. $ tiffgt rietkleur004.tif displays the picture decently. $ tiffinfo rietkleur004.tif TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.. TIFF Directory at offset 0x1a51b08 (27597576) Image Width: 2144 Image Length: 3218 Bits/Sample: 8 Compression Scheme: None Photometric Interpretation: RGB color Samples/Pixel: 4 Planar Configuration: single image plane Seems OK. $ tiffsplit rietkleur004.tif TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.. There is nothing really to split, but it generates a decent xaaa.tif file, copy of the original picture. OK for me. ]$ tiffmedian rietkleur007.tif riklmed007.tif TIFFReadDirectory: Warning, Sum of Photometric type-related color channels and ExtraSamples doesn't match SamplesPerPixel. Defining non-color channels as ExtraSamples.. produces an akward color picture with only a few week but quite different colors. I guess that's what I asked for. If Lewis can get to the end of his quest, I'll agree to OK this update despite the commands with problems. BTW, eom cannot open these tiff files, but gwenview works OK on those.
CC: (none) => herman.viaene
@lewis, comment 9. May have time today to look at CVE-2018-18557. @herman: comment 10. The eom + tiff files problem looks like an old one.
CC: (none) => tarazed25
Mageia 6, x86_64 Following this link (comment CVE-2018-18557 https://www.exploit-db.com/exploits/45694 Downloaded the C file and compiled it. $ gcc -o tifftest -ljbig tifftest.c Downloaded the base64 file from the same site then spent a lot of time trying to find a way to decode it. base64 decoding is not well documented. Tried openssl enc with the -d option and uudecode. Both failed on the raw data. Googling turned up some discussion on using php to decode base64 text. Transmogrified one of the scripts from a forum (thanks Tobias): http://php.net/manual/en/function.base64-decode.php $ cat decoder.php <?php $ifp = fopen( "crashtiff.txt", "rb" ); $imageData = fread( $ifp, filesize( "crashtiff.txt" ) ); fclose( $ifp ); /* encode & write data (binary) */ $ifp = fopen( "decoded", "wb" ); fwrite( $ifp, base64_decode( $imageData ) ); fclose( $ifp ); /* return output filename */ return( "decoded" ); ?> $ php decoder.php $ file decoded decoded: TIFF image data, little-endian, direntries=14, height=150, bps=1, compression=JBIG, PhotometricIntepretation=WhiteIsZero, width=150 $ ./tifftest decoded Segmentation fault (core dumped) Not sure if this is caused by errors in my procedure or if this is the failure expected. To be checked after the update. On the question of eom and eog; urpmq --requires-recursive shows no connection with tiff libraries.
CVE-2018-18557 $ hexdump -C decoded | head 00000000 49 49 2a 00 48 18 00 00 32 30 30 31 3a 31 31 3a |II*.H...2001:11:| 00000010 32 37 20 32 31 3a 34 30 3a 32 38 00 38 00 00 00 |27 21:40:28.8...| 00000020 01 00 00 00 38 00 00 00 00 01 00 00 00 00 01 00 |....8...........| [...] Quite an old file. After updating libtiff packages, recompiled the test program. $ ./tifftest decoded Segmentation fault (core dumped) Hmm. tiffgt never works on this machine. $ tiffgt xaaa.tif libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast freeglut (tiffgt): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow $ tiffgt decoded libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast freeglut (tiffgt): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow Same result with other TIFF files. $ display decoded display: Invalid TIFF directory; tags are not sorted in ascending order. `TIFFReadDirectoryCheckOrder' @ warning/tiff.c/TIFFWarnings/913. display: Decoded 6039 bytes, whereas 2850 were requested. `JBIG' @ error/tiff.c/TIFFErrors/569. An strace shows that libtiff is called as well as ImageMagick's own tiff.so coders. This is an improvement. The image was displayed - a white square. Forgot to report that this test failed with an abort before the update. We can say that this bug has been fixed and with all the tests which Lewis and Herman have done the package can be sent on its way.
Created attachment 10620 [details] PoC test program for CVE-2018-18557 To compile: $ $ gcc -o tifftest -ljbig tifftest.c
Thanks to our heavyweights for the additional verifications. No need to add more. OKing both 32 (no crashes) & 64. Advisory & validating.
Whiteboard: (none) => MGA6-32-OK MGA6-64-OKKeywords: (none) => advisory, validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0493.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED