Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure

[Niko Tyni]

(re-adding Cc: tiff at pdo)

On Sat, Dec 02, 2023 at 01:40:51PM +0100, gregor herrmann wrote:
> On Sat, 02 Dec 2023 14:24:01 +0200, Niko Tyni wrote:
> 
> > It regressed with tiff_4.5.1+git230720-2 which is currently blocked from
> > migrating to trixie because libimager-perl autopkgtests are failing too.
> > 
> > Changes:
> >  tiff (4.5.1+git230720-2) unstable; urgency=high
> >  .
> >    * Backport security fix for CVE-2023-6277, passing a crafted tiff file to
> >      TIFFOpen() API may allow a remote attacker to cause a denial of service
> >      (closes: #1056751).
> > 
> > I see libimager-perl upstream has released 1.021 with some tiff related
> > changes. I haven't checked if those fix the issue, or whether libtiff
> > is actually broken. Feel free to reassign as needed.
> 
> I've imported 1.021 into our git repo yesterday, and there it fails
> the same way (I hadn't nticed that 1.020 in sid also fails …)
> 
> So -- is this a bug in Imager or in tiff?

Can't quite say, but sharing what I found:

The test creates TIFF/testout/t106.tiff with
Imager::File::TIFF::i_writetiff_wiol() and then tries to read it back with

  open(FH,"testout/t106.tiff") or die "cannot open testout/t106.tiff\n";
  binmode(FH);
  $IO = Imager::io_new_fd(fileno(FH));
  my $cmpimg = Imager::File::TIFF::i_readtiff_wiol($IO);

Adding an Imager->_error_as_msg() call after that gives

  Error opening file: Failed to read directory at offset 37014 at TIFF/t/t10tiff.t line 49.

Also there's t106tiff.log with plenty of diagnostics including

  [2023/12/02 16:29:42]   imtiff.c:237     1: tiff warning Requested memory size for TIFF directory of 168 is greather than filesize 0. Memory not allocated, TIFF directory not read

which matches the CVE-2023-6277 changes in libtiff, see

  https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/debian/patches/CVE-2023-6277.patch/

It can be reproduced like this with the libimager-perl binaries
currently in sid and every tiff file I tried with, for example
test/images/palette-1c-8b.tiff in src:tiff.

  https://sources.debian.org/src/tiff/4.5.1%2Bgit230720-2/test/images/palette-1c-8b.tiff/

  $ perl -MImager::File::TIFF -E '$i = Imager::io_new_fd(*STDIN); Imager::init_log(); Imager::File::TIFF::i_readtiff_wiol($i) or die Imager->_error_as_msg' < tiff/test/images/palette-1c-8b.tiff
  [2023/12/02 17:16:03]      log.c:56      0: Imager - log started (level = 1)
  [2023/12/02 17:16:03]  Imager.xs:267     1: Imager 1.020 starting
  [2023/12/02 17:16:03]   imtiff.c:700     1: i_readtiff_wiol(ig 0x55a6ece33890, allow_incomplete 0, page 0)
  [2023/12/02 17:16:03]       io.c:242     1: mymalloc(size 8192) -> 0x55a6ed426e70
  [2023/12/02 17:16:03]   imtiff.c:237     1: tiff warning Requested memory size for TIFF directory of 180 is greather than filesize 0. Memory not allocated, TIFF directory not read
  [2023/12/02 17:16:03]       io.c:266     1: myrealloc(block (nil), size 124)
  [2023/12/02 17:16:03]   imtiff.c:201     1: tiff error fmt Failed to read directory at offset %lu
  [2023/12/02 17:16:03]       io.c:242     1: mymalloc(size 41) -> 0x55a6ece1d480
  [2023/12/02 17:16:03]   imtiff.c:715     1: i_readtiff_wiol: Unable to open tif file
  [2023/12/02 17:16:03]       io.c:242     1: mymalloc(size 19) -> 0x55a6ed36be90
  [2023/12/02 17:16:03]       io.c:253     1: myfree(p 0x55a6ed42e250)
  Error opening file: Failed to read directory at offset 23716 at -e line 1.
  [2023/12/02 17:16:03]  iolayer.c:424     1: io_glue_DESTROY(ig 0x55a6ece33890)
 
I note it says "filesize 0". The patch determines the file size with

  uint64_t filesize = TIFFGetFileSize(tif);

and TIFFGetFileSize() is in src:tiff libtiff/tiffiop.h as follows:

  #define TIFFGetFileSize(tif) ((*(tif)->tif_sizeproc)((tif)->tif_clientdata))

which is where I called it a day :)

So I suppose the way Imager reads the file here does not initialize the
data structure in a way that the patched libtiff expects?
-- 
Niko