Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Tue, Dec 05, 2023 at 10:01:17PM +0100, Salvatore Bonaccorso wrote: > On Sun, Dec 03, 2023 at 03:05:09PM +0200, Niko Tyni wrote: > > While the stable update tiff_4.5.0-6+deb12u1 has security fixes, it does > > not include the change for CVE-2023-6277. The security tracker mentions > > it as a minor issue. I also checked earlier that stable is not affected. > > But would mean once we will pick CVE-2023-6277 libimager-perl in > bookworm or bullseye will break, correct? Yes, I think so. -- Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
Hi all, On Sun, Dec 03, 2023 at 03:05:09PM +0200, Niko Tyni wrote: > On Sun, Dec 03, 2023 at 01:31:19AM +0100, gregor herrmann wrote: > > On Sun, 03 Dec 2023 10:46:50 +1100, Tony Cook wrote: > > > > > > https://github.com/tonycoz/imager/issues/522 > > > Fixed in 1.022, please let me know if you have any more problems. > > > > Thank you! > > 1.022 builds fine in Debian unstable, so I've uploaded it. > > Thanks! > > > > d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick > > > back to 1.020 if you don't want all of the 1.021 TIFF changes in > > > the debian stable libimager-perl. > > > > Hm, Debian stable (which has 1.019) is a good question. If libtiff is > > updated there too [0] we might see the same issue there. > > While the stable update tiff_4.5.0-6+deb12u1 has security fixes, it does > not include the change for CVE-2023-6277. The security tracker mentions > it as a minor issue. I also checked earlier that stable is not affected. But would mean once we will pick CVE-2023-6277 libimager-perl in bookworm or bullseye will break, correct? I have expanded the note on the security-tracker relating to the issue. Regards, Salvatore
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Sun, Dec 03, 2023 at 01:31:19AM +0100, gregor herrmann wrote: > On Sun, 03 Dec 2023 10:46:50 +1100, Tony Cook wrote: > > > > https://github.com/tonycoz/imager/issues/522 > > Fixed in 1.022, please let me know if you have any more problems. > > Thank you! > 1.022 builds fine in Debian unstable, so I've uploaded it. Thanks! > > d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick > > back to 1.020 if you don't want all of the 1.021 TIFF changes in > > the debian stable libimager-perl. > > Hm, Debian stable (which has 1.019) is a good question. If libtiff is > updated there too [0] we might see the same issue there. While the stable update tiff_4.5.0-6+deb12u1 has security fixes, it does not include the change for CVE-2023-6277. The security tracker mentions it as a minor issue. I also checked earlier that stable is not affected. > So I guess we don't have to do anything here, and if reality is > different than my tests, we can pull in > d54ea521f63ec1ed7d8c0fd11c23507600d51143 -- thanks for the pointer! Agreed & thanks again :) -- Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Sun, 03 Dec 2023 10:46:50 +1100, Tony Cook wrote: > > https://github.com/tonycoz/imager/issues/522 > Fixed in 1.022, please let me know if you have any more problems. Thank you! 1.022 builds fine in Debian unstable, so I've uploaded it. > d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick > back to 1.020 if you don't want all of the 1.021 TIFF changes in > the debian stable libimager-perl. Hm, Debian stable (which has 1.019) is a good question. If libtiff is updated there too [0] we might see the same issue there. Same experimentation later: It looks like building libimager-perl 1.019+dfsg-1 from stable in a stable chroot with an additional source stable-security which pulls in libtiff-dev 4.5.0-6+deb12u1 -- still succeeds. So I guess we don't have to do anything here, and if reality is different than my tests, we can pull in d54ea521f63ec1ed7d8c0fd11c23507600d51143 -- thanks for the pointer! Cheers, gregor [0] tiff | 4.5.0-6 | stable | source tiff | 4.5.0-6+deb12u1 | proposed-updates | source -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
On Sat, Dec 02, 2023 at 08:35:38PM +0200, Niko Tyni wrote:
> >From
> >https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302
>
> static toff_t sizeproc(thandle_t x) {
> return 0;
> }
>
> which is used as the TIFFClientOpen() argument in i_readtiff_wiol():
>
>
> https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710
>
> So it looks like libimager-perl is always saying the file size is 0,
> and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
> patch.
>
> Not sure where this leaves us, but I've just reported it at
>
> https://github.com/tonycoz/imager/issues/522
Fixed in 1.022, please let me know if you have any more problems.
d54ea521f63ec1ed7d8c0fd11c23507600d51143 should be safe to cherry pick
back to 1.020 if you don't want all of the 1.021 TIFF changes in
the debian stable libimager-perl.
Thanks,
Tony
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
Control: forwarded -1 https://github.com/tonycoz/imager/issues/522
On Sat, Dec 02, 2023 at 07:24:39PM +0200, Niko Tyni wrote:
> 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 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.
Further simplifying, this fails in the exact same way:
$ perl -MImager -e '$i=Imager->new; Imager::init_log(); $i->read(file =>
shift) or die $i->_error_as_msg()' tiff/test/images/palette-1c-8b.tiff
> 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))
>From http://www.simplesystems.org/libtiff/functions/TIFFOpen.html
TIFFClientOpen() is like TIFFOpen() except that the caller supplies a
collection of functions that the library will use to do UNIX-like I/O
operations. The readproc and writeproc functions are called to read and
write data at the current file position. seekproc is called to change
the current file position à la lseek() (2). closeproc is invoked to
release any resources associated with an open file. sizeproc is invoked
to obtain the size in bytes of a file. mapproc and unmapproc are called
to map and unmap a file's contents in memory; c.f. mmap() (2) and
munmap() (2). The clientdata parameter is an opaque "handle" passed to
the client-specified routines passed as parameters to TIFFClientOpen().
>From
>https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L302
static toff_t sizeproc(thandle_t x) {
return 0;
}
which is used as the TIFFClientOpen() argument in i_readtiff_wiol():
https://sources.debian.org/src/libimager-perl/1.020%2Bdfsg-1/TIFF/imtiff.c/#L710
So it looks like libimager-perl is always saying the file size is 0,
and this hasn't hurt earlier but now does with the src:tiff CVE-2023-6277
patch.
Not sure where this leaves us, but I've just reported it at
https://github.com/tonycoz/imager/issues/522
--
Niko
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
(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
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
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? Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#1057270: libimager-perl: FTBFS: t/t10tiff.t failure
Source: libimager-perl Version: 1.020+dfsg-1 Severity: serious Tags: ftbfs Control: block 1055955 with -1 X-Debbugs-Cc: t...@packages.debian.org This package fails to build from source on current sid. 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'm marking this as a blocker for the Perl 5.38 transition as we need to be able to rebuild libimager-perl for that. >From the build log: # libtiff release 4.5.1 # Failed test 'read low-level' # at t/t10tiff.t line 49. Use of uninitialized value in subroutine entry at t/t10tiff.t line 53. Use of uninitialized value in subroutine entry at t/t10tiff.t line 53. im2 is not of type Imager::ImgRaw at t/t10tiff.t line 53. # Looks like your test exited with 25 just after 4. t/t10tiff.t .. 1..247 ok 1 - use Imager::File::TIFF; ok 2 - extract library version ok 3 - write low level not ok 4 - read low-level Dubious, test returned 25 (wstat 6400, 0x1900) Failed 244/247 subtests Test Summary Report --- t/t10tiff.t (Wstat: 6400 (exited 25) Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 25 Parse errors: Bad plan. You planned 247 tests but ran 4. Files=1, Tests=4, 0 wallclock secs ( 0.01 usr 0.01 sys + 0.10 cusr 0.02 csys = 0.14 CPU) Result: FAIL A full build log is at http://perl.debian.net/rebuild-logs/sid/libimager-perl_1.020%2Bdfsg-1/libimager-perl_1.020%2Bdfsg-1_amd64-2023-12-02T11%3A49%3A48Z.build -- Niko Tyni nt...@debian.org
