tiff: CVE-2018-7456: null pointer dereference

Debian Bug report logs - #891288
tiff: CVE-2018-7456: null pointer dereference

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: tiff: CVE-2018-7456: null pointer dereference

Date: Sat, 24 Feb 2018 10:23:35 +0100

Source: tiff
Version: 4.0.9-3
Severity: important
Tags: security upstream
Forwarded: http://bugzilla.maptools.org/show_bug.cgi?id=2778

Hi,

the following vulnerability was published for tiff.

CVE-2018-7456[0]:
| A NULL Pointer Dereference occurs in the function TIFFPrintDirectory in
| tif_print.c in LibTIFF 4.0.9 when using the tiffinfo tool to print
| crafted TIFF information, a different vulnerability than
| CVE-2017-18013. (This affects an earlier part of the TIFFPrintDirectory
| function that was not addressed by the CVE-2017-18013 patch.)

Note that this is a different issue than CVE-2017-18013. Attached is
the poc from the reporter.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7456
    https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7456
[1] http://bugzilla.maptools.org/show_bug.cgi?id=2778

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Message #10 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: 891288@bugs.debian.org

Subject: Re: Bug#891288: tiff: CVE-2018-7456: null pointer dereference

Date: Sat, 24 Feb 2018 10:31:49 +0100

[Message part 1 (text/plain, inline)]

On Sat, Feb 24, 2018 at 10:23:35AM +0100, Salvatore Bonaccorso wrote:
> Note that this is a different issue than CVE-2017-18013. Attached is
> the poc from the reporter.

Now for real.

Regards,
Salvatore

[1-tiffinfo-c-null.base64 (text/plain, attachment)]

Message #15 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: debian-lts@lists.debian.org

Cc: Brian May <bam@debian.org>, 891288@bugs.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Sat, 17 Mar 2018 22:42:40 +0100

[Message part 1 (text/plain, inline)]

So, after some debugging on CVE-2018-7456, I start to get the feeling to
understand the issue.

Here are my conclusions for the moment:

* In any case, the transfer function should not care about other
  channels defined by ExtraSamples (see 2nd and 3rd paragraphs of
  TransferFunction entry, page 84 of the specification), so something
  like the following patch should be a first step:

--- a/libtiff/tif_print.c	2018-03-17 21:56:47.000000000 +0100
+++ b/libtiff/tif_print.c	2018-03-17 22:05:58.446092016 +0100
@@ -546,7 +546,7 @@
 				uint16 i;
 				fprintf(fd, "    %2ld: %5u",
 				    l, td->td_transferfunction[0][l]);
-				for (i = 1; i < td->td_samplesperpixel; i++)
+				for (i = 1; i < td->td_samplesperpixel - td->td_extrasamples; i++)
 					fprintf(fd, " %5u",
 					    td->td_transferfunction[i][l]);
 				fputc('\n', fd);

But it's not enough. Why ?

* I discovered that td->td_samplesperpixel can have arbitrary size while
  td->td_extrasamples stays 0. It shouldn't be the case ! For instance
  the specification doesn't allow RGB with 4 channels and no ExtraSamples.
  And while it doesn't make any sense, libtiff won't notice it.

  I even tried RGB with 8 channels and no ExtraSamples and it worked too.

  So, what should be done ?

  For each PhotometricInterpretation type there is a 'standard' samples
  per pixel value (that is the samples per pixel value without extra samples:
  3 for RGB, etc). Let's name it (standard spp).

  So, what we should do is: If the actual td->td_samplesperpixel is higher
  than (standard spp), then we should assume that td->td_extrasamples is
  td->td_samplesperpixel - (standard spp), even if no ExtraSamples field
  was specified OR if the specified td->td_extrasamples was smaller.

  Obviously we should also take care of filling appropriate
  td->td_sampleinfo entries.

  For example, if an RGB image has td->td_samplesperpixel = 4, then
  td->td_extrasamples should be set to 1 (with arbitrary
  td->td_sampleinfo entry for example 0 - Unspecified data).

Does it work now ?

I think so ! I didn't write the second part of the patch and will wait
for feedback. But you can convince yourself that it doesn't crash anymore
by modifying the sample to add an ExtraSamples = 1 field (using
"tiffset -s 338 1 0 $(sample)" for example).

Link to the specification:
https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pdf

Regards,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Brian May <bam@debian.org>

To: Hugo Lefeuvre <hle@debian.org>, debian-lts@lists.debian.org

Cc: 891288@bugs.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Sun, 18 Mar 2018 13:06:54 +1100

Hugo Lefeuvre <hle@debian.org> writes:

> So, after some debugging on CVE-2018-7456, I start to get the feeling to
> understand the issue.
>
> Here are my conclusions for the moment:
>
> * In any case, the transfer function should not care about other
>   channels defined by ExtraSamples (see 2nd and 3rd paragraphs of
>   TransferFunction entry, page 84 of the specification), so something
>   like the following patch should be a first step:
>
> --- a/libtiff/tif_print.c	2018-03-17 21:56:47.000000000 +0100
> +++ b/libtiff/tif_print.c	2018-03-17 22:05:58.446092016 +0100
> @@ -546,7 +546,7 @@
>  				uint16 i;
>  				fprintf(fd, "    %2ld: %5u",
>  				    l, td->td_transferfunction[0][l]);
> -				for (i = 1; i < td->td_samplesperpixel; i++)
> +				for (i = 1; i < td->td_samplesperpixel - td->td_extrasamples; i++)
>  					fprintf(fd, " %5u",
>  					    td->td_transferfunction[i][l]);
>  				fputc('\n', fd);
>
> But it's not enough. Why ?
>
> * I discovered that td->td_samplesperpixel can have arbitrary size while
>   td->td_extrasamples stays 0. It shouldn't be the case ! For instance
>   the specification doesn't allow RGB with 4 channels and no ExtraSamples.
>   And while it doesn't make any sense, libtiff won't notice it.
>
>   I even tried RGB with 8 channels and no ExtraSamples and it worked too.
>
>   So, what should be done ?
>
>   For each PhotometricInterpretation type there is a 'standard' samples
>   per pixel value (that is the samples per pixel value without extra samples:
>   3 for RGB, etc). Let's name it (standard spp).
>
>   So, what we should do is: If the actual td->td_samplesperpixel is higher
>   than (standard spp), then we should assume that td->td_extrasamples is
>   td->td_samplesperpixel - (standard spp), even if no ExtraSamples field
>   was specified OR if the specified td->td_extrasamples was smaller.

Seems good to me. I would suggest sending a patch upstream, see what
they think.

Also I tend to think some some of assertion might be a good idea,
something that aborts if

(td->td_samplesperpixel - td->td_extrasamples) > 3

As aborting early is probably better then screwing up memory.


For reference, the next value in the struct is:

typedef struct {
        [...]

        /* Colorimetry parameters */
	uint16* td_transferfunction[3];
	float*	td_refblackwhite;

        [...]
} TIFFDirectory;

So I am guessing when you access td_transferfunction[3], you are
actually accessing td_refblackwhite, which - surprise surprise - happens
to be NULL.
-- 
Brian May <bam@debian.org>

Message #25 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: Brian May <bam@debian.org>

Cc: debian-lts@lists.debian.org, 891288@bugs.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Sun, 18 Mar 2018 09:23:29 +0100

[Message part 1 (text/plain, inline)]

> Seems good to me. I would suggest sending a patch upstream, see what
> they think.

Thanks for the feedback ! I'll write the remaining part and submit it to
upstream.
 
> Also I tend to think some some of assertion might be a good idea,
> something that aborts if
> 
> (td->td_samplesperpixel - td->td_extrasamples) > 3
> 
> As aborting early is probably better then screwing up memory.
> 
> For reference, the next value in the struct is:
> 
> typedef struct {
>         [...]
> 
>         /* Colorimetry parameters */
> 	uint16* td_transferfunction[3];
> 	float*	td_refblackwhite;
> 
>         [...]
> } TIFFDirectory;
> 
> So I am guessing when you access td_transferfunction[3], you are
> actually accessing td_refblackwhite, which - surprise surprise - happens
> to be NULL.

While we could certainly do that, I'm not 100% convinced it would be a
good idea, mostly because it would involve a magic number (3), which
we should IMO try to avoid.

Also, if td is spec-compliant, then

    td->td_samplesperpixel - td->td_extrasamples

should never be greater than 3 (unless the spec evolves, which is fine
anyways as long as the size of td_transferfunction is re-defined)
because otherwise it would break the assumption

    td->td_extrasamples = td->td_samplesperpixel - (standard spp)

which we expect to be guaranteed by the callee.

But, right, something like

    /* Should be guaranted by callee */
    (td->td_samplesperpixel - td->td_extrasamples) > TD_TRANSFER_FUNCTION_SIZE

and also

    typedef struct {
           [...]

           /* Colorimetry parameters */
           uint16* td_transferfunction[TD_TRANSFER_FUNCTION_SIZE];
           float*  td_refblackwhite;

           [...]
    } TIFFDirectory;

could clearly be a good idea, at least because it would make the
patch/code clearer on what we are trying to do and what assumption we
make.

Thanks !

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 891288@bugs.debian.org

Cc: Brian May <bam@debian.org>, debian-lts@lists.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Tue, 20 Mar 2018 14:58:28 +0100

[Message part 1 (text/plain, inline)]

Hi,

> Thanks for the feedback ! I'll write the remaining part and submit it to
> upstream.

You can find a first draft in attachment.

While it's already a working solution (at least, I think), there's
still place for improvements.

* I'm not sure that the check it well positioned in the source code
* I still fear some redundancy with some other similar (but irrelevant in our
  case) code at libtiff/tif_getimage.c:326

Also, I've double checked and RGB is the only case to handle. Palette
should have SamplePerPixel = 1, AFAIK BlackIsZero/WhiteIsZero should not
specify this field and YCbCr should always have SamplePerPixel = 3.

Feedback welcome.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[CVE-2018-7456-v2.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 891288@bugs.debian.org

Cc: Brian May <bam@debian.org>, debian-lts@lists.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Tue, 20 Mar 2018 15:34:54 +0100

[Message part 1 (text/plain, inline)]

> Also, I've double checked and RGB is the only case to handle. Palette
> should have SamplePerPixel = 1, AFAIK BlackIsZero/WhiteIsZero should not
> specify this field and YCbCr should always have SamplePerPixel = 3.

Well, this is actually wrong because the code actually doesn't perform
*any* kind of checks regarding this.

I have modified the original sample so we have some more test data:

a) RGB with samplesPerPixel = 8, extraSamples = 0
b) RGB with samplesPerPixel = 8, extraSamples = 2
c) BIZ with samplesPerPixel = 4, extraSamples = 0
d) PALETTE with samplesPerPixel = 4, extraSamples = 0

a) & b) fine, c) and d) are not covered by the patch yet and still crash.

I'll submit an updated version of the fix.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[1-tiffinfo-c-null-8-spp (application/octet-stream, attachment)]

[1-tiffinfo-c-null-biz (application/octet-stream, attachment)]

[1-tiffinfo-c-null-es-2 (application/octet-stream, attachment)]

[1-tiffinfo-c-null-pal (application/octet-stream, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 891288@bugs.debian.org

Cc: debian-lts@lists.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Wed, 21 Mar 2018 11:26:47 +0100

[Message part 1 (text/plain, inline)]

You can find an updated patch in attachment.

While the TIFFGetColorChannels function is probably not the most elegant
solution, the if block in TIFFReadDirectory would be by far less readable
without it.

Also, I've written a detailed description of the changes:

    The TIFFPrintDirectory relies on the following assumptions supposed
    to be guaranteed by the specification:

     (a) A Transfer Function field is only present if the TIFF file has
         photometric type < 3.

     (b) If SamplesPerPixel > Color Channels, then the ExtraSamples field
         has count SamplesPerPixel - (Color Channels) and contains
         information about supplementary channels.

    While the respect of (a) and (b) are essential for the functioning of
    TIFFPrintDirectory, no checks are realized neither by the callee nor
    by TIFFPrintDirectory itself. Hence, following scenarios might happen
    and trigger CVE-2018-7456:

     (1) TIFF File of photometric type 4 or more has illegal Transfer
          Function field.

     (2) TIFF File has photometric type 3 or less and defines a
         SamplesPerPixel field such that SamplesPerPixel > Color Channels
         without declaring ExtraSamples.

    In this patch, we are trying to fix both issues with respect of the
    following principles:

     (A) In the case of (1), the defined transfer table should be printed
         safely even if it isn't 'legal'. This allows us to avoid expensive
         checks in TIFFPrintDirectory. Also, it is quite possible that
         an alternative photometric type would be developed (not part of the
         standard) and would allow definition of Transfer Table. We want
         libtiff to be able to handle this scenario out of the box.

     (B) In the case of (2), the transfer table should be printed at its
         right size, that is if TIFF file has photometric type Palette
         then the transfer table should have one row and not three, even
         if two extra samples are declared.

    Some comments on the patch:

     - The for loop in TIFFPrintDirectory has now two end conditions:
       'i < td->td_samplesperpixel - td->td_extrasamples' addresses (B)
       and 'i < 3' addresses (A).

     - 'i < td->td_samplesperpixel - td->td_extrasamples' is useless if
       we don't modify libtiff/tif_dirread.c to fix the ExtraSamples
       field: All non-color channels should be defined as ExtraSamples.

     - Alternatively the 'i < td->td_samplesperpixel - td->td_extrasamples'
       condition could be replaced by 'i < TIFFGetColorChannels(td->td_photometric)'
       but while this would make the patch clearly smaller this is IMO
       not the best idea because:

        * TIFFPrintDirectory is a print function and should not contain
          too much logic

        * Other parts of the source code may still rely on such
          assumptions and will still be vulnerable if we put the check
          in TIFFPrintDirectory

You can find test data for (1) in attachment.

I'll submit this patch to upstream and see if I can get some feedback.

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[CVE-2018-7456-v3.patch (text/x-diff, attachment)]

[1-tiffinfo-c-null-itulab (application/octet-stream, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 891288@bugs.debian.org

Subject: Re: tiff / CVE-2018-7456

Date: Sun, 8 Apr 2018 14:45:46 -0400

[Message part 1 (text/plain, inline)]

Hi,

I didn't get any feedback on the bug report. I have reworked my patch
and issued a merge requested on Gitlab[0].

Regards,
 Hugo

[0] https://gitlab.com/libtiff/libtiff/merge_requests/27

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: 891288@bugs.debian.org

Subject: Re: Bug#891288: tiff: CVE-2018-7456: null pointer dereference

Date: Fri, 13 Apr 2018 05:17:40 +0200

Control: tags -1 + fixed-upstream

The issue was fixed upstream via https://gitlab.com/libtiff/libtiff/commit/be4c85b16e8801a16eec25e80eb9f3dd6a96731b

Regards,
Salvatore

Message #57 received at 891288@bugs.debian.org (full text, mbox, reply):

From: Hugo Lefeuvre <hle@debian.org>

To: 891288@bugs.debian.org

Cc: Salvatore Bonaccorso <carnil@debian.org>

Subject: Re: Bug#891288: tiff: CVE-2018-7456: null pointer dereference

Date: Sun, 15 Apr 2018 00:08:32 -0400

[Message part 1 (text/plain, inline)]

Hi,

My MR was accepted. I'm going to backport the fix to Wheezy tomorrow,
should I also prepare a patch for Jessie & Stretch at the same time ?

Cheers,
 Hugo

-- 
             Hugo Lefeuvre (hle)    |    www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA

[signature.asc (application/pgp-signature, inline)]

Message #62 received at 891288@bugs.debian.org (full text, mbox, reply):

From: László Böszörményi (GCS) <gcs@debian.org>

To: Hugo Lefeuvre <hle@debian.org>, 891288@bugs.debian.org

Cc: Salvatore Bonaccorso <carnil@debian.org>

Subject: Re: Bug#891288: tiff: CVE-2018-7456: null pointer dereference

Date: Sun, 15 Apr 2018 07:19:41 +0200

Hi Hugo,

On Sun, Apr 15, 2018 at 6:08 AM, Hugo Lefeuvre <hle@debian.org> wrote:
> My MR was accepted. I'm going to backport the fix to Wheezy tomorrow,
> should I also prepare a patch for Jessie & Stretch at the same time ?
 Thanks for the offer - I would like to do it late in the afternoon
when I get back home.

Cheers,
Laszlo/GCS

Message #67 received at 891288-close@bugs.debian.org (full text, mbox, reply):

From: Laszlo Boszormenyi (GCS) <gcs@debian.org>

To: 891288-close@bugs.debian.org

Subject: Bug#891288: fixed in tiff 4.0.9-5

Date: Sun, 15 Apr 2018 19:21:51 +0000

Source: tiff
Source-Version: 4.0.9-5

We believe that the bug you reported is fixed in the latest version of
tiff, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 891288@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Laszlo Boszormenyi (GCS) <gcs@debian.org> (supplier of updated tiff package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 15 Apr 2018 18:13:42 +0000
Source: tiff
Binary: libtiff5 libtiffxx5 libtiff5-dev libtiff-dev libtiff-tools libtiff-opengl libtiff-doc
Architecture: source amd64 all
Version: 4.0.9-5
Distribution: unstable
Urgency: high
Maintainer: Laszlo Boszormenyi (GCS) <gcs@debian.org>
Changed-By: Laszlo Boszormenyi (GCS) <gcs@debian.org>
Description:
 libtiff-dev - Tag Image File Format library (TIFF), development files, current
 libtiff-doc - TIFF manipulation and conversion documentation
 libtiff-opengl - TIFF manipulation and conversion tools
 libtiff-tools - TIFF manipulation and conversion tools
 libtiff5   - Tag Image File Format (TIFF) library
 libtiff5-dev - Tag Image File Format library (TIFF), development files
 libtiffxx5 - Tag Image File Format (TIFF) library -- C++ interface
Closes: 869823 883320 891288
Changes:
 tiff (4.0.9-5) unstable; urgency=high
 .
   * Fix CVE-2017-11613: avoid memory exhaustion in
     ChopUpSingleUncompressedStrip() (closes: #869823).
   * Fix CVE-2018-7456: NULL pointer dereference in TIFFPrintDirectory()
     (closes: #891288).
   * Fix CVE-2017-17095: heap-based buffer overflow in pal2rgb tool
     (closes: #883320).
   * Don't specify parallel to debhelper.
   * Update Standards-Version to 4.1.4 .
Checksums-Sha1:
 89b5b03490d29c89bdc8d29e5adbca11cfddc0ac 2184 tiff_4.0.9-5.dsc
 c7b31db61dd17d89ee488790e1c906bf8f3abce6 22864 tiff_4.0.9-5.debian.tar.xz
 bf21c77518a73eda63408a7e1a16fa4c9162d9ed 96320 libtiff-dev_4.0.9-5_amd64.deb
 0e3fa54f22ab387932fd212d1f6096d3b1697705 403280 libtiff-doc_4.0.9-5_all.deb
 c302361f0ba12dde13e789583909869425d6ed45 13752 libtiff-opengl-dbgsym_4.0.9-5_amd64.deb
 be246ae589c9d27b5230fd3fa6704e5423937513 104848 libtiff-opengl_4.0.9-5_amd64.deb
 e4a34497cb9bb20e7de6310b26af0ef6f635227e 348292 libtiff-tools-dbgsym_4.0.9-5_amd64.deb
 28b6d4ea00c51df2958a0c7657c9495b7d0aa91f 286980 libtiff-tools_4.0.9-5_amd64.deb
 f1ae499bf30e7790f59876430f7c3c5b3f2aad1f 376692 libtiff5-dbgsym_4.0.9-5_amd64.deb
 1cb41b832591670bda407f6c3492af6f216c5472 367464 libtiff5-dev_4.0.9-5_amd64.deb
 8ccdd356549d6dd52ddf3b1d7f5e4ec3b8ded1cb 245632 libtiff5_4.0.9-5_amd64.deb
 cfb90d9bd23407bfbfb92027820c81ba880ff0e1 21268 libtiffxx5-dbgsym_4.0.9-5_amd64.deb
 8900e34afc3d7353bbf314a6fd93f11c412e1bf3 100044 libtiffxx5_4.0.9-5_amd64.deb
 7168331074f126952da9ea23e8efd899a3cc4dbf 12131 tiff_4.0.9-5_amd64.buildinfo
Checksums-Sha256:
 f708f46910204e0a009edd7ae709fd7c9a4b467775d36ca4160aab290c195bd6 2184 tiff_4.0.9-5.dsc
 5c98180b77457fc5452f3b4fed85862172dbfdb342d7a98e88363e439a669c96 22864 tiff_4.0.9-5.debian.tar.xz
 7667bb7574545c2131b7bf9c2dccd072364edd5be94d25255d6558dc64d9ef72 96320 libtiff-dev_4.0.9-5_amd64.deb
 776955232fb4606537a2282ebbc6c307587201823cede71328e0cc5e43de987c 403280 libtiff-doc_4.0.9-5_all.deb
 615e9c1ed3f6c89dfd43671c208a621dd1e5129ce0a97cd897255d5fbd2ba621 13752 libtiff-opengl-dbgsym_4.0.9-5_amd64.deb
 9d95a4784b10001b736dabedfb5a5a8fd1623769bb9ae527a7e27f8ab0f1e4a0 104848 libtiff-opengl_4.0.9-5_amd64.deb
 5022d7ae68a550a079c6ba2b8c8d632e84f828fd1006e992c1e8ce0be719ebdf 348292 libtiff-tools-dbgsym_4.0.9-5_amd64.deb
 1a8d88b79e690e9f504e293f8bdb224f05f2587c2ac4ee104975042ae4708430 286980 libtiff-tools_4.0.9-5_amd64.deb
 95a97d09eb954bb0c228c9aad4f6a4f596231fa13675a444fad5a65f0e3c449e 376692 libtiff5-dbgsym_4.0.9-5_amd64.deb
 f8585c5ffc1f8ca593ea045f760c91e5c1b2ecaffe33fd2ff35d59e29a962a54 367464 libtiff5-dev_4.0.9-5_amd64.deb
 18778122ad6201d8edb41d1bc79fb14415ce51ee83e24d3d0b6a3230fcfbcd9d 245632 libtiff5_4.0.9-5_amd64.deb
 8810671bfe2bd766877b4c50ef444937efaf1a2ba654acaa90b2b59270c97aa8 21268 libtiffxx5-dbgsym_4.0.9-5_amd64.deb
 64e79614a1a71c2f142ffb7c86a7e41a959c2d18e5bcf8ea9010c102c05d3f1b 100044 libtiffxx5_4.0.9-5_amd64.deb
 ac2de2cc65b42ce63c39ddb3fcd06280bb801814a7264f1e9b6a284df0b6b814 12131 tiff_4.0.9-5_amd64.buildinfo
Files:
 7c4518cdeb95460173802a748ce76c6e 2184 libs optional tiff_4.0.9-5.dsc
 22d7c422438c6270fe7ac79913f86d0d 22864 libs optional tiff_4.0.9-5.debian.tar.xz
 225464e88da83a85836b867c5d8f2ddc 96320 oldlibs optional libtiff-dev_4.0.9-5_amd64.deb
 99f1c8d8e02fffe5ba05493b640338cf 403280 doc optional libtiff-doc_4.0.9-5_all.deb
 18cedeff0aecb5e0dc19e2115c4b2b19 13752 debug optional libtiff-opengl-dbgsym_4.0.9-5_amd64.deb
 3c3656858197d4d71da034521c27ef8d 104848 graphics optional libtiff-opengl_4.0.9-5_amd64.deb
 7ef79531d8b9d189f1b1cb64ebcd21ff 348292 debug optional libtiff-tools-dbgsym_4.0.9-5_amd64.deb
 b413e56e2a5dcb3054fed7f30f745c67 286980 graphics optional libtiff-tools_4.0.9-5_amd64.deb
 4be386931aa02908e4d711ce0c09a5e0 376692 debug optional libtiff5-dbgsym_4.0.9-5_amd64.deb
 a0fef22485949f76a4ee3c18962d6687 367464 libdevel optional libtiff5-dev_4.0.9-5_amd64.deb
 b8f62d32fbfc65dafeb4c163bcefc5c7 245632 libs optional libtiff5_4.0.9-5_amd64.deb
 ab2901df81dc64a57bf4d653cae37cb3 21268 debug optional libtiffxx5-dbgsym_4.0.9-5_amd64.deb
 ccfc7dc5cea835633b9a292a621b5e48 100044 libs optional libtiffxx5_4.0.9-5_amd64.deb
 b932630b31e4e31e6506f79174d0c2c7 12131 libs optional tiff_4.0.9-5_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEfYh9yLp7u6e4NeO63OMQ54ZMyL8FAlrToMYACgkQ3OMQ54ZM
yL+MFxAAojHYv2PylcGrTFNGDBwDLDHjka/8aH33JCoG641qPtlZDLrtw84bPOOW
Y9I0gIA6rJzxH0ajbx6ifTlDzrO5Gon9E6R+DZqTesayjB7iw5X60vIFIqfADolt
USGOAGeU9y2oZTvNKuWXucfszJ0dRJwm7Uz2WZEkRlSQVUv8CMsa8XTk7BoTEo/2
TzDnS5OsX5jXKYZnbbakbpJNfTW+4mFdeVWBIQwhDEDD0yZ4rHr8j50F8vkASbVq
H7IwDerapBgYba7a27wOFmteDw4meeKofokJAM5b4juwlrYzLP1KKEESztLSh4K9
2cHf+vBRSPBsTasuINkW0PhLfAovsf6vkonWrkXqcOzBk8NNwOb1HXO4CO3JmADD
S2TlyXZf6kJLRzLUwZoZZXc6YgVlggDDXt0Tp88C+T5aHafqpsuC0C0bIU+0sueo
cs4QxFK6ptyEz7MQe8nW3Co27flO7CI9uXhWf85VNc1u/0cLxUXchuO1NInPgvhu
qY5pY8BzRciaz4sD1Ctx8j32LxVQjz+lPrVnUgJ6/PgxLUi+jDt1JxrfgKXLwYUz
QiBbN8WeZa1v5vehwHLkZD+bkpRAbwO4d4ojy0L3AhEDV9UwAy/06IR7FjZWuHPS
++tqaIpkbFg+9uVwJ/tm/uXdEZVlrtK6rLpgDzkFJTtovHR8DW4=
=gKts
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.