Re: possible regressing in tiff4/libtiff3 update (deb7u1)
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/
Reply to: