(re-adding Cc: tiff@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
