Hello Matthias, On Thu, 26 Jan 2017, Matthias Geerdsen wrote: > we noticed a possible regression in an update to libtiff4 which leads to > corrupted image files when using ImageMagick/GraphicsMagick mogrify > command to apply jpeg compression to a tiff image. I have shortly > described the problem in bug #852610 [1]. It appears this was already > introduced in 3.9.6-11+deb7u1
Right. So the reported problem (invalid tag Predictor) can be avoided by dropping the patch debian/patches/CVE-2014-8128-5-fixed.patch but then you get another similar error message: $ convert -compress JPEG sample.tif out.tif convert.im6: out.tif: Invalid tag "BadFaxLines" (not supported by codec). `_TIFFVGetField' @ error/tiff.c/TIFFErrors/513. And I'm not sure that backing out those changes is the correct approach. In fact we explicitly added more field description to avoid issues when we find unknown tags and parse them with an incorrect format. So it's actually a security feature that the code is able to reject tags that are not allowed in the file given the codec in use. So maybe it's actually imagemagick that is at fault here. Matthias, please report back what version of imagemagick do you have just to make sure we are on the same page... (I did my tries with 8:6.7.7.10-5+deb7u10). But then when I look at the code, I don't really know where those supplementary tags come from... and there are more of those: $ diff -u <(tiffdump sample.tif) <(tiffdump out.tif) --- /dev/fd/63 2017-01-26 15:36:33.703686356 +0000 +++ /dev/fd/62 2017-01-26 15:36:33.707686376 +0000 @@ -1,20 +1,25 @@ -sample.tif: +out.tif: Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF> -Directory 0: offset 12296 (0x3008) next 0 (0) -SubFileType (254) LONG (4) 1<0> +Directory 0: offset 1122 (0x462) next 0 (0) ImageWidth (256) SHORT (3) 1<64> ImageLength (257) SHORT (3) 1<64> BitsPerSample (258) SHORT (3) 3<8 8 8> -Compression (259) SHORT (3) 1<1> +Compression (259) SHORT (3) 1<7> Photometric (262) SHORT (3) 1<2> -DocumentName (269) ASCII (2) 19</tmp/Unbenannt.tif\0> +FillOrder (266) SHORT (3) 1<1> +DocumentName (269) ASCII (2) 8<out.tif\0> ImageDescription (270) ASCII (2) 18<Created with GIMP\0> -StripOffsets (273) LONG (4) 1<8> +StripOffsets (273) LONG (4) 2<8 855> Orientation (274) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<3> -RowsPerStrip (278) SHORT (3) 1<64> -StripByteCounts (279) LONG (4) 1<12288> +RowsPerStrip (278) SHORT (3) 1<48> +StripByteCounts (279) LONG (4) 2<847 267> XResolution (282) RATIONAL (5) 1<72> YResolution (283) RATIONAL (5) 1<72> PlanarConfig (284) SHORT (3) 1<1> ResolutionUnit (296) SHORT (3) 1<2> +PageNumber (297) SHORT (3) 2<0 1> +Predictor (317) SHORT (3) 1<2> +Whitepoint (318) RATIONAL (5) 2<0.3127 0.329> +PrimaryChromaticities (319) RATIONAL (5) 6<0.64 0.33 0.3 0.6 0.15 0.06> +YCbCrSubsampling (530) SHORT (3) 2<2 2> In fact JPEGTABLES and PREDICTOR and BADFAXLINES both share the same "field_bit" (FIELD_CODEC+0) so it might just be that the error message is misleading and is telling us something about the JPEGTABLES tag that would be expected with JPEG compression. This would be coherent with the content of a successfully converted file wich looks like this: out.tif: Magic: 0x4949 <little-endian> Version: 0x2a <ClassicTIFF> Directory 0: offset 1122 (0x462) next 0 (0) ImageWidth (256) SHORT (3) 1<64> ImageLength (257) SHORT (3) 1<64> BitsPerSample (258) SHORT (3) 3<8 8 8> Compression (259) SHORT (3) 1<7> Photometric (262) SHORT (3) 1<2> FillOrder (266) SHORT (3) 1<1> DocumentName (269) ASCII (2) 8<out.tif\0> ImageDescription (270) ASCII (2) 18<Created with GIMP\0> StripOffsets (273) LONG (4) 2<8 855> Orientation (274) SHORT (3) 1<1> SamplesPerPixel (277) SHORT (3) 1<3> RowsPerStrip (278) SHORT (3) 1<48> StripByteCounts (279) LONG (4) 2<847 267> XResolution (282) RATIONAL (5) 1<72> YResolution (283) RATIONAL (5) 1<72> PlanarConfig (284) SHORT (3) 1<1> ResolutionUnit (296) SHORT (3) 1<2> PageNumber (297) SHORT (3) 2<0 1> Whitepoint (318) RATIONAL (5) 2<0.3127 0.329> PrimaryChromaticities (319) RATIONAL (5) 6<0.64 0.33 0.3 0.6 0.15 0.06> JPEGTables (347) UNDEFINED (7) 289<0xff 0xd8 0xff 0xdb 00 0x43 00 0x8 0x6 0x6 0x7 0x6 0x5 0x8 0x7 0x7 0x7 0x9 0x9 0x8 0xa 0xc 0x14 0xd ...> YCbCrSubsampling (530) SHORT (3) 2<2 2> But I have currently no idea of what the problem really is. And upstream has not yet merge any similar change to what we have done. At least https://github.com/vadz/libtiff/blob/master/libtiff/tif_dirinfo.c shows neither PREDICTOR nor BADFAXLINES. So we are a bit on our own here. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
