#27603 [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

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

From: Alex Vong <alexvong1995@gmail.com>

To: guix-patches@gnu.org

Subject: [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

Date: Fri, 07 Jul 2017 06:31:36 +0800

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

Severity: important
Tags: patch security

Hello,

This patch fixes two latest CVEs of libtiff:

[0001-gnu-libtiff-Fix-CVE-2017-9936-10688.patch (text/x-diff, inline)]

From 8dc3ff7b6b34b1d0ff7ab535883df20dbc5af2c8 Mon Sep 17 00:00:00 2001
From: Alex Vong <alexvong1995@gmail.com>
Date: Fri, 7 Jul 2017 06:17:37 +0800
Subject: [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

* gnu/packages/patches/libtiff-CVE-2017-9936.patch,
  gnu/packages/patches/libtiff-CVE-2017-10688.patch: New files.
* gnu/packages/image.scm (libtiff-4.0.8)[source]: Add patches.
* gnu/local.mk (dist_patch_DATA): Add them.
---
 gnu/local.mk                                      |  2 +
 gnu/packages/image.scm                            |  4 +-
 gnu/packages/patches/libtiff-CVE-2017-10688.patch | 80 +++++++++++++++++++++++
 gnu/packages/patches/libtiff-CVE-2017-9936.patch  | 39 +++++++++++
 4 files changed, 124 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/libtiff-CVE-2017-10688.patch
 create mode 100644 gnu/packages/patches/libtiff-CVE-2017-9936.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 8dbce7c05..4ae395ef8 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -766,6 +766,8 @@ dist_patch_DATA =						\
   %D%/packages/patches/libtiff-CVE-2016-10093.patch		\
   %D%/packages/patches/libtiff-CVE-2016-10094.patch		\
   %D%/packages/patches/libtiff-CVE-2017-5225.patch		\
+  %D%/packages/patches/libtiff-CVE-2017-9936.patch		\
+  %D%/packages/patches/libtiff-CVE-2017-10688.patch		\
   %D%/packages/patches/libtiff-assertion-failure.patch		\
   %D%/packages/patches/libtiff-divide-by-zero-ojpeg.patch	\
   %D%/packages/patches/libtiff-divide-by-zero-tiffcp.patch	\
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 8a03cbc3c..4450980bf 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -391,7 +391,9 @@ collection of tools for doing simple manipulations of TIFF images.")
        (method url-fetch)
        (uri (string-append "ftp://download.osgeo.org/libtiff/tiff-"
                            version ".tar.gz"))
-       (patches (search-patches "libtiff-tiffgetfield-bugs.patch"))
+       (patches (search-patches "libtiff-tiffgetfield-bugs.patch"
+                                "libtiff-CVE-2017-9936.patch"
+                                "libtiff-CVE-2017-10688.patch"))
        (sha256
         (base32
          "0419mh6kkhz5fkyl77gv0in8x4d2jpdpfs147y8mj86rrjlabmsr"))))))
diff --git a/gnu/packages/patches/libtiff-CVE-2017-10688.patch b/gnu/packages/patches/libtiff-CVE-2017-10688.patch
new file mode 100644
index 000000000..3b5d27fd7
--- /dev/null
+++ b/gnu/packages/patches/libtiff-CVE-2017-10688.patch
@@ -0,0 +1,80 @@
+Fix CVE-2017-10688:
+
+http://bugzilla.maptools.org/show_bug.cgi?id=2712
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-10688
+https://security-tracker.debian.org/tracker/CVE-2017-10688
+
+Patch lifted from upstream source repository (the changes to 'ChangeLog'
+don't apply to the libtiff 4.0.8 release tarball):
+
+https://github.com/vadz/libtiff/commit/6173a57d39e04d68b139f8c1aa499a24dbe74ba1
+
+From 6173a57d39e04d68b139f8c1aa499a24dbe74ba1 Mon Sep 17 00:00:00 2001
+From: Even Rouault <even.rouault@spatialys.com>
+Date: Fri, 30 Jun 2017 17:29:44 +0000
+Subject: [PATCH] * libtiff/tif_dirwrite.c: in
+ TIFFWriteDirectoryTagCheckedXXXX() functions associated with LONG8/SLONG8
+ data type, replace assertion that the file is BigTIFF, by a non-fatal error.
+ Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2712 Reported by team
+ OWL337
+
+---
+ ChangeLog              |  8 ++++++++
+ libtiff/tif_dirwrite.c | 20 ++++++++++++++++----
+ 2 files changed, 24 insertions(+), 4 deletions(-)
+
+diff --git a/libtiff/tif_dirwrite.c b/libtiff/tif_dirwrite.c
+index 2967da58..8d6686ba 100644
+--- a/libtiff/tif_dirwrite.c
++++ b/libtiff/tif_dirwrite.c
+@@ -2111,7 +2111,10 @@ TIFFWriteDirectoryTagCheckedLong8(TIFF* tif, uint32* ndir, TIFFDirEntry* dir, ui
+ {
+ 	uint64 m;
+ 	assert(sizeof(uint64)==8);
+-	assert(tif->tif_flags&TIFF_BIGTIFF);
++	if( !(tif->tif_flags&TIFF_BIGTIFF) ) {
++		TIFFErrorExt(tif->tif_clientdata,"TIFFWriteDirectoryTagCheckedLong8","LONG8 not allowed for ClassicTIFF");
++		return(0);
++	}
+ 	m=value;
+ 	if (tif->tif_flags&TIFF_SWAB)
+ 		TIFFSwabLong8(&m);
+@@ -2124,7 +2127,10 @@ TIFFWriteDirectoryTagCheckedLong8Array(TIFF* tif, uint32* ndir, TIFFDirEntry* di
+ {
+ 	assert(count<0x20000000);
+ 	assert(sizeof(uint64)==8);
+-	assert(tif->tif_flags&TIFF_BIGTIFF);
++	if( !(tif->tif_flags&TIFF_BIGTIFF) ) {
++		TIFFErrorExt(tif->tif_clientdata,"TIFFWriteDirectoryTagCheckedLong8","LONG8 not allowed for ClassicTIFF");
++		return(0);
++	}
+ 	if (tif->tif_flags&TIFF_SWAB)
+ 		TIFFSwabArrayOfLong8(value,count);
+ 	return(TIFFWriteDirectoryTagData(tif,ndir,dir,tag,TIFF_LONG8,count,count*8,value));
+@@ -2136,7 +2142,10 @@ TIFFWriteDirectoryTagCheckedSlong8(TIFF* tif, uint32* ndir, TIFFDirEntry* dir, u
+ {
+ 	int64 m;
+ 	assert(sizeof(int64)==8);
+-	assert(tif->tif_flags&TIFF_BIGTIFF);
++	if( !(tif->tif_flags&TIFF_BIGTIFF) ) {
++		TIFFErrorExt(tif->tif_clientdata,"TIFFWriteDirectoryTagCheckedLong8","SLONG8 not allowed for ClassicTIFF");
++		return(0);
++	}
+ 	m=value;
+ 	if (tif->tif_flags&TIFF_SWAB)
+ 		TIFFSwabLong8((uint64*)(&m));
+@@ -2149,7 +2158,10 @@ TIFFWriteDirectoryTagCheckedSlong8Array(TIFF* tif, uint32* ndir, TIFFDirEntry* d
+ {
+ 	assert(count<0x20000000);
+ 	assert(sizeof(int64)==8);
+-	assert(tif->tif_flags&TIFF_BIGTIFF);
++	if( !(tif->tif_flags&TIFF_BIGTIFF) ) {
++		TIFFErrorExt(tif->tif_clientdata,"TIFFWriteDirectoryTagCheckedLong8","SLONG8 not allowed for ClassicTIFF");
++		return(0);
++	}
+ 	if (tif->tif_flags&TIFF_SWAB)
+ 		TIFFSwabArrayOfLong8((uint64*)value,count);
+ 	return(TIFFWriteDirectoryTagData(tif,ndir,dir,tag,TIFF_SLONG8,count,count*8,value));
+-- 
+2.13.2
+
diff --git a/gnu/packages/patches/libtiff-CVE-2017-9936.patch b/gnu/packages/patches/libtiff-CVE-2017-9936.patch
new file mode 100644
index 000000000..a3d51e0ef
--- /dev/null
+++ b/gnu/packages/patches/libtiff-CVE-2017-9936.patch
@@ -0,0 +1,39 @@
+Fix CVE-2017-9936:
+
+http://bugzilla.maptools.org/show_bug.cgi?id=2706
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9936
+https://security-tracker.debian.org/tracker/CVE-2017-9936
+
+Patch lifted from upstream source repository (the changes to 'ChangeLog'
+don't apply to the libtiff 4.0.8 release tarball):
+
+https://github.com/vadz/libtiff/commit/fe8d7165956b88df4837034a9161dc5fd20cf67a
+
+From fe8d7165956b88df4837034a9161dc5fd20cf67a Mon Sep 17 00:00:00 2001
+From: Even Rouault <even.rouault@spatialys.com>
+Date: Mon, 26 Jun 2017 15:19:59 +0000
+Subject: [PATCH] * libtiff/tif_jbig.c: fix memory leak in error code path of
+ JBIGDecode() Fixes http://bugzilla.maptools.org/show_bug.cgi?id=2706 Reported
+ by team OWL337
+
+* libtiff/tif_jpeg.c: error out at decoding time if anticipated libjpeg
+---
+ ChangeLog          | 8 +++++++-
+ libtiff/tif_jbig.c | 1 +
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/libtiff/tif_jbig.c b/libtiff/tif_jbig.c
+index 5f5f75e2..c75f31d9 100644
+--- a/libtiff/tif_jbig.c
++++ b/libtiff/tif_jbig.c
+@@ -94,6 +94,7 @@ static int JBIGDecode(TIFF* tif, uint8* buffer, tmsize_t size, uint16 s)
+ 			     jbg_strerror(decodeStatus)
+ #endif
+ 			     );
++		jbg_dec_free(&decoder);
+ 		return 0;
+ 	}
+ 
+-- 
+2.13.2
+
-- 
2.13.2

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

Cheers,
Alex

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

Message #8 received at 27603@debbugs.gnu.org (full text, mbox, reply):

From: Leo Famulari <leo@famulari.name>

To: Alex Vong <alexvong1995@gmail.com>

Cc: 27603@debbugs.gnu.org

Subject: Re: [bug#27603] [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

Date: Thu, 6 Jul 2017 19:40:38 -0400

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

On Fri, Jul 07, 2017 at 06:31:36AM +0800, Alex Vong wrote:
> * gnu/packages/patches/libtiff-CVE-2017-9936.patch,
>   gnu/packages/patches/libtiff-CVE-2017-10688.patch: New files.
> * gnu/packages/image.scm (libtiff-4.0.8)[source]: Add patches.
> * gnu/local.mk (dist_patch_DATA): Add them.

> +Patch lifted from upstream source repository (the changes to 'ChangeLog'
> +don't apply to the libtiff 4.0.8 release tarball):
> +
> +https://github.com/vadz/libtiff/commit/6173a57d39e04d68b139f8c1aa499a24dbe74ba1

This is actually not the upstream source repository. It's a 3rd party
unofficial mirror.

To the chagrin of young packagers everywhere, libtiff is still using
CVS. Unless somebody beats me to it, I'll extract the patches from their
CVS repo later tonight.

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

Message #13 received at 27603-done@debbugs.gnu.org (full text, mbox, reply):

From: Leo Famulari <leo@famulari.name>

To: Alex Vong <alexvong1995@gmail.com>

Cc: 27603-done@debbugs.gnu.org

Subject: Re: [bug#27603] [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

Date: Fri, 7 Jul 2017 00:07:26 -0400

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

On Thu, Jul 06, 2017 at 07:40:38PM -0400, Leo Famulari wrote:
> On Fri, Jul 07, 2017 at 06:31:36AM +0800, Alex Vong wrote:
> > * gnu/packages/patches/libtiff-CVE-2017-9936.patch,
> >   gnu/packages/patches/libtiff-CVE-2017-10688.patch: New files.
> > * gnu/packages/image.scm (libtiff-4.0.8)[source]: Add patches.
> > * gnu/local.mk (dist_patch_DATA): Add them.
> 
> > +Patch lifted from upstream source repository (the changes to 'ChangeLog'
> > +don't apply to the libtiff 4.0.8 release tarball):
> > +
> > +https://github.com/vadz/libtiff/commit/6173a57d39e04d68b139f8c1aa499a24dbe74ba1
> 
> This is actually not the upstream source repository. It's a 3rd party
> unofficial mirror.
> 
> To the chagrin of young packagers everywhere, libtiff is still using
> CVS. Unless somebody beats me to it, I'll extract the patches from their
> CVS repo later tonight.

I pushed this as dab536fe1ae5a8775a2b50fa50556445b6ac7818. Thanks for
getting it started Alex!

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

Message #16 received at 27603-done@debbugs.gnu.org (full text, mbox, reply):

From: Alex Vong <alexvong1995@gmail.com>

To: Leo Famulari <leo@famulari.name>

Cc: 27603-done@debbugs.gnu.org

Subject: Re: [bug#27603] [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

Date: Fri, 07 Jul 2017 21:20:07 +0800

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

Leo Famulari <leo@famulari.name> writes:

> On Thu, Jul 06, 2017 at 07:40:38PM -0400, Leo Famulari wrote:
>> On Fri, Jul 07, 2017 at 06:31:36AM +0800, Alex Vong wrote:
>> > * gnu/packages/patches/libtiff-CVE-2017-9936.patch,
>> >   gnu/packages/patches/libtiff-CVE-2017-10688.patch: New files.
>> > * gnu/packages/image.scm (libtiff-4.0.8)[source]: Add patches.
>> > * gnu/local.mk (dist_patch_DATA): Add them.
>> 
>> > +Patch lifted from upstream source repository (the changes to 'ChangeLog'
>> > +don't apply to the libtiff 4.0.8 release tarball):
>> > +
>> > +https://github.com/vadz/libtiff/commit/6173a57d39e04d68b139f8c1aa499a24dbe74ba1
>> 
>> This is actually not the upstream source repository. It's a 3rd party
>> unofficial mirror.
>>
Ahhh, I blindly used the links from debian security tracker. Should have
been more careful. I wonder why they use links from an unofficial mirror.

>> To the chagrin of young packagers everywhere, libtiff is still using
>> CVS. Unless somebody beats me to it, I'll extract the patches from their
>> CVS repo later tonight.
>
:)

> I pushed this as dab536fe1ae5a8775a2b50fa50556445b6ac7818. Thanks for
> getting it started Alex!

You're welcomed!

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

Message #19 received at 27603-done@debbugs.gnu.org (full text, mbox, reply):

From: Leo Famulari <leo@famulari.name>

To: Alex Vong <alexvong1995@gmail.com>

Cc: 27603-done@debbugs.gnu.org

Subject: Re: [bug#27603] [PATCH] gnu: libtiff: Fix CVE-2017-{9936,10688}.

Date: Fri, 7 Jul 2017 12:30:47 -0400

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

On Fri, Jul 07, 2017 at 09:20:07PM +0800, Alex Vong wrote:
> Ahhh, I blindly used the links from debian security tracker. Should have
> been more careful. I wonder why they use links from an unofficial mirror.

I noticed they were doing that, and I don't understand why. It *is*
convenient to have a relatively stable changeset ID in the form of Git
commit hashes.

I asked about it on oss-security and the repo was confirmed to be
unofficial:

http://seclists.org/oss-sec/2017/q1/15

It has been acknowledged by the libtiff maintainer:

http://maptools-org.996276.n3.nabble.com/git-version-control-td13746.html

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

Send a report that this bug log contains spam.