Libtiff CVE-2016-5652

Libtiff CVE-2016-5652

[Leo Famulari]

[-- Attachment #1.1: Type: text/plain, Size: 954 bytes --]

I read this 3rd party security advisory about libtiff:

http://blog.talosintel.com/2016/10/LibTIFF-Code-Execution.html

This patch fixes CVE-2016-5652, which is a buffer overflow with
potential for remote code execution.

You can easily view the commit in this unofficial Git mirror of the
libtiff CVS repo:
https://github.com/vadz/libtiff/commit/b5d6803f0898e931cf772d3d0755704ab8488e63

Unfortunately, that's the closest thing to an "official" upstream
reference to the bug that is viewable in a web browser that I can find.

I had to also take the previous change to the affected file, since the
bug fix commit depended on those changes.

This patched libtiff does _seem_ to work properly; I viewed a TIFF file
with it.

One of the bugs in that Talos advisory, CVE-2016-8331, is apparently
still not fixed upstream. And CVE-2016-5875 appears to me to be fixed by
our patch for CVE-2016-5314 [0].

[0]
http://bugzilla.maptools.org/show_bug.cgi?id=2554

[-- Attachment #1.2: 0001-gnu-libtiff-Fix-CVE-2016-5652.patch --]
[-- Type: text/plain, Size: 3959 bytes --]

From 7abe86a8d93e1a1ed11f14ec7ede22ce9b020611 Mon Sep 17 00:00:00 2001
From: Leo Famulari <leo@famulari.name>
Date: Sat, 29 Oct 2016 19:23:05 -0400
Subject: [PATCH] gnu: libtiff: Fix CVE-2016-5652.

* gnu/packages/patches/libtiff-CVE-2016-5652.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/image.scm (libtiff/fixed)[source]: Use it.
---
 gnu/local.mk                                     |  1 +
 gnu/packages/image.scm                           |  3 +-
 gnu/packages/patches/libtiff-CVE-2016-5652.patch | 47 ++++++++++++++++++++++++
 3 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/libtiff-CVE-2016-5652.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index a64b7ec..1942131 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -657,6 +657,7 @@ dist_patch_DATA =						\
   %D%/packages/patches/libtiff-CVE-2016-5314.patch		\
   %D%/packages/patches/libtiff-CVE-2016-5321.patch		\
   %D%/packages/patches/libtiff-CVE-2016-5323.patch		\
+  %D%/packages/patches/libtiff-CVE-2016-5652.patch		\
   %D%/packages/patches/libtiff-oob-accesses-in-decode.patch	\
   %D%/packages/patches/libtiff-oob-write-in-nextdecode.patch	\
   %D%/packages/patches/libtool-skip-tests2.patch		\
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index 873a7f2..3a1209f 100644
--- a/gnu/packages/image.scm
+++ b/gnu/packages/image.scm
@@ -234,7 +234,8 @@ collection of tools for doing simple manipulations of TIFF images.")
                          "libtiff-CVE-2016-3991.patch"
                          "libtiff-CVE-2016-5314.patch"
                          "libtiff-CVE-2016-5321.patch"
-                         "libtiff-CVE-2016-5323.patch"))))))
+                         "libtiff-CVE-2016-5323.patch"
+                         "libtiff-CVE-2016-5652.patch"))))))
 
 (define-public libwmf
   (package
diff --git a/gnu/packages/patches/libtiff-CVE-2016-5652.patch b/gnu/packages/patches/libtiff-CVE-2016-5652.patch
new file mode 100644
index 0000000..54b87d0
--- /dev/null
+++ b/gnu/packages/patches/libtiff-CVE-2016-5652.patch
@@ -0,0 +1,47 @@
+Fix CVE-2016-5652 (buffer overflow in t2p_readwrite_pdf_image_tile()).
+
+https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5652
+
+Patches exfiltrated from upstream CVS repo with:
+cvs diff -u -r 1.92 -r 1.94 tools/tiff2pdf.c
+
+Index: tools/tiff2pdf.c
+===================================================================
+RCS file: /cvs/maptools/cvsroot/libtiff/tools/tiff2pdf.c,v
+retrieving revision 1.92
+retrieving revision 1.94
+diff -u -r1.92 -r1.94
+--- a/tools/tiff2pdf.c	23 Sep 2016 22:12:18 -0000	1.92
++++ b/tools/tiff2pdf.c	9 Oct 2016 11:03:36 -0000	1.94
+@@ -2887,21 +2887,24 @@
+ 				return(0);
+ 			}
+ 			if(TIFFGetField(input, TIFFTAG_JPEGTABLES, &count, &jpt) != 0) {
+-				if (count > 0) {
+-					_TIFFmemcpy(buffer, jpt, count);
++				if (count >= 4) {
++                    /* Ignore EOI marker of JpegTables */
++					_TIFFmemcpy(buffer, jpt, count - 2);
+ 					bufferoffset += count - 2;
++                    /* Store last 2 bytes of the JpegTables */
+ 					table_end[0] = buffer[bufferoffset-2];
+ 					table_end[1] = buffer[bufferoffset-1];
+-				}
+-				if (count > 0) {
+ 					xuint32 = bufferoffset;
++                    bufferoffset -= 2;
+ 					bufferoffset += TIFFReadRawTile(
+ 						input, 
+ 						tile, 
+-						(tdata_t) &(((unsigned char*)buffer)[bufferoffset-2]), 
++						(tdata_t) &(((unsigned char*)buffer)[bufferoffset]), 
+ 						-1);
+-						buffer[xuint32-2]=table_end[0];
+-						buffer[xuint32-1]=table_end[1];
++                    /* Overwrite SOI marker of image scan with previously */
++                    /* saved end of JpegTables */
++					buffer[xuint32-2]=table_end[0];
++					buffer[xuint32-1]=table_end[1];
+ 				} else {
+ 					bufferoffset += TIFFReadRawTile(
+ 						input, 
-- 
2.10.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Libtiff CVE-2016-5652

[Ludovic Courtès]

Leo Famulari <leo@famulari.name> skribis:

> I read this 3rd party security advisory about libtiff:
>
> http://blog.talosintel.com/2016/10/LibTIFF-Code-Execution.html
>
> This patch fixes CVE-2016-5652, which is a buffer overflow with
> potential for remote code execution.
>
> You can easily view the commit in this unofficial Git mirror of the
> libtiff CVS repo:
> https://github.com/vadz/libtiff/commit/b5d6803f0898e931cf772d3d0755704ab8488e63
>
> Unfortunately, that's the closest thing to an "official" upstream
> reference to the bug that is viewable in a web browser that I can find.

But now you master CVS anyway, don’t you?  ;-)

> I had to also take the previous change to the affected file, since the
> bug fix commit depended on those changes.
>
> This patched libtiff does _seem_ to work properly; I viewed a TIFF file
> with it.
>
> One of the bugs in that Talos advisory, CVE-2016-8331, is apparently
> still not fixed upstream. And CVE-2016-5875 appears to me to be fixed by
> our patch for CVE-2016-5314 [0].

Hmm.

> From 7abe86a8d93e1a1ed11f14ec7ede22ce9b020611 Mon Sep 17 00:00:00 2001
> From: Leo Famulari <leo@famulari.name>
> Date: Sat, 29 Oct 2016 19:23:05 -0400
> Subject: [PATCH] gnu: libtiff: Fix CVE-2016-5652.
>
> * gnu/packages/patches/libtiff-CVE-2016-5652.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/image.scm (libtiff/fixed)[source]: Use it.

I’d say go for it.

0 days since the last image library vulnerability…

Thank you!
Ludo’.

Re: Libtiff CVE-2016-5652

[Leo Famulari]

On Sun, Oct 30, 2016 at 10:56:41PM +0100, Ludovic Courtès wrote:
> Leo Famulari <leo@famulari.name> skribis:
> > From 7abe86a8d93e1a1ed11f14ec7ede22ce9b020611 Mon Sep 17 00:00:00 2001
> > From: Leo Famulari <leo@famulari.name>
> > Date: Sat, 29 Oct 2016 19:23:05 -0400
> > Subject: [PATCH] gnu: libtiff: Fix CVE-2016-5652.
> >
> > * gnu/packages/patches/libtiff-CVE-2016-5652.patch: New file.
> > * gnu/local.mk (dist_patch_DATA): Add it.
> > * gnu/packages/image.scm (libtiff/fixed)[source]: Use it.
> 
> I’d say go for it.

Pushed to master and merged into core-updates. I kept it grafted on
core-updates, since changing libtiff requires ~1500 rebuilds. Oh well.
It's a good candidate for a post-release "staging" branch.

> 0 days since the last image library vulnerability…

I don't think we'll need 64 bits for this counter...