030fe340af
Add upstream post-4.0.7 commits (except for ChangeLog modifications) fixing the following security issues: CVE-2016-10266 - LibTIFF 4.0.7 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted TIFF image, related to libtiff/tif_read.c:351:22. CVE-2016-10267 - LibTIFF 4.0.7 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted TIFF image, related to libtiff/tif_ojpeg.c:816:8. CVE-2016-10269 - LibTIFF 4.0.7 allows remote attackers to cause a denial of service (heap-based buffer over-read) or possibly have unspecified other impact via a crafted TIFF image, related to "READ of size 512" and libtiff/tif_unix.c:340:2. CVE-2016-10270 - LibTIFF 4.0.7 allows remote attackers to cause a denial of service (heap-based buffer over-read) or possibly have unspecified other impact via a crafted TIFF image, related to "READ of size 8" and libtiff/tif_read.c:523:22. CVE-2017-5225 - LibTIFF version 4.0.7 is vulnerable to a heap buffer overflow in the tools/tiffcp resulting in DoS or code execution via a crafted BitsPerSample value. CVE-2017-7592 - The putagreytile function in tif_getimage.c in LibTIFF 4.0.7 has a left-shift undefined behavior issue, which might allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted image. CVE-2017-7593 - tif_read.c in LibTIFF 4.0.7 does not ensure that tif_rawdata is properly initialized, which might allow remote attackers to obtain sensitive information from process memory via a crafted image. CVE-2017-7594 - The OJPEGReadHeaderInfoSecTablesDcTable function in tif_ojpeg.c in LibTIFF 4.0.7 allows remote attackers to cause a denial of service (memory leak) via a crafted image. CVE-2017-7595 - The JPEGSetupEncode function in tiff_jpeg.c in LibTIFF 4.0.7 allows remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted image. CVE-2017-7598 - tif_dirread.c in LibTIFF 4.0.7 might allow remote attackers to cause a denial of service (divide-by-zero error and application crash) via a crafted image. CVE-2017-7601 - LibTIFF 4.0.7 has a "shift exponent too large for 64-bit type long" undefined behavior issue, which might allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted image. CVE-2017-7602 - LibTIFF 4.0.7 has a signed integer overflow, which might allow remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact via a crafted image. Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
111 lines
4.0 KiB
Diff
111 lines
4.0 KiB
Diff
From 1044b43637fa7f70fb19b93593777b78bd20da86 Mon Sep 17 00:00:00 2001
|
|
From: erouault <erouault>
|
|
Date: Fri, 2 Dec 2016 23:05:51 +0000
|
|
Subject: [PATCH] * libtiff/tif_pixarlog.c, libtiff/tif_luv.c: fix heap-based
|
|
buffer overflow on generation of PixarLog / LUV compressed files, with
|
|
ColorMap, TransferFunction attached and nasty plays with bitspersample. The
|
|
fix for LUV has not been tested, but suffers from the same kind of issue of
|
|
PixarLog. Reported by Agostino Sarubbo. Fixes
|
|
http://bugzilla.maptools.org/show_bug.cgi?id=2604
|
|
|
|
Fixes CVE-2016-10269
|
|
|
|
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
|
|
---
|
|
libtiff/tif_luv.c | 18 ++++++++++++++----
|
|
libtiff/tif_pixarlog.c | 17 +++++++++++++++--
|
|
2 files changed, 39 insertions(+), 6 deletions(-)
|
|
|
|
diff --git a/libtiff/tif_luv.c b/libtiff/tif_luv.c
|
|
index f68a9b13..e6783db5 100644
|
|
--- a/libtiff/tif_luv.c
|
|
+++ b/libtiff/tif_luv.c
|
|
@@ -158,6 +158,7 @@
|
|
typedef struct logLuvState LogLuvState;
|
|
|
|
struct logLuvState {
|
|
+ int encoder_state; /* 1 if encoder correctly initialized */
|
|
int user_datafmt; /* user data format */
|
|
int encode_meth; /* encoding method */
|
|
int pixel_size; /* bytes per pixel */
|
|
@@ -1552,6 +1553,7 @@ LogLuvSetupEncode(TIFF* tif)
|
|
td->td_photometric, "must be either LogLUV or LogL");
|
|
break;
|
|
}
|
|
+ sp->encoder_state = 1;
|
|
return (1);
|
|
notsupported:
|
|
TIFFErrorExt(tif->tif_clientdata, module,
|
|
@@ -1563,19 +1565,27 @@ notsupported:
|
|
static void
|
|
LogLuvClose(TIFF* tif)
|
|
{
|
|
+ LogLuvState* sp = (LogLuvState*) tif->tif_data;
|
|
TIFFDirectory *td = &tif->tif_dir;
|
|
|
|
+ assert(sp != 0);
|
|
/*
|
|
* For consistency, we always want to write out the same
|
|
* bitspersample and sampleformat for our TIFF file,
|
|
* regardless of the data format being used by the application.
|
|
* Since this routine is called after tags have been set but
|
|
* before they have been recorded in the file, we reset them here.
|
|
+ * Note: this is really a nasty approach. See PixarLogClose
|
|
*/
|
|
- td->td_samplesperpixel =
|
|
- (td->td_photometric == PHOTOMETRIC_LOGL) ? 1 : 3;
|
|
- td->td_bitspersample = 16;
|
|
- td->td_sampleformat = SAMPLEFORMAT_INT;
|
|
+ if( sp->encoder_state )
|
|
+ {
|
|
+ /* See PixarLogClose. Might avoid issues with tags whose size depends
|
|
+ * on those below, but not completely sure this is enough. */
|
|
+ td->td_samplesperpixel =
|
|
+ (td->td_photometric == PHOTOMETRIC_LOGL) ? 1 : 3;
|
|
+ td->td_bitspersample = 16;
|
|
+ td->td_sampleformat = SAMPLEFORMAT_INT;
|
|
+ }
|
|
}
|
|
|
|
static void
|
|
diff --git a/libtiff/tif_pixarlog.c b/libtiff/tif_pixarlog.c
|
|
index d1246c3d..aa99bc92 100644
|
|
--- a/libtiff/tif_pixarlog.c
|
|
+++ b/libtiff/tif_pixarlog.c
|
|
@@ -1233,8 +1233,10 @@ PixarLogPostEncode(TIFF* tif)
|
|
static void
|
|
PixarLogClose(TIFF* tif)
|
|
{
|
|
+ PixarLogState* sp = (PixarLogState*) tif->tif_data;
|
|
TIFFDirectory *td = &tif->tif_dir;
|
|
|
|
+ assert(sp != 0);
|
|
/* In a really sneaky (and really incorrect, and untruthful, and
|
|
* troublesome, and error-prone) maneuver that completely goes against
|
|
* the spirit of TIFF, and breaks TIFF, on close, we covertly
|
|
@@ -1243,8 +1245,19 @@ PixarLogClose(TIFF* tif)
|
|
* readers that don't know about PixarLog, or how to set
|
|
* the PIXARLOGDATFMT pseudo-tag.
|
|
*/
|
|
- td->td_bitspersample = 8;
|
|
- td->td_sampleformat = SAMPLEFORMAT_UINT;
|
|
+
|
|
+ if (sp->state&PLSTATE_INIT) {
|
|
+ /* We test the state to avoid an issue such as in
|
|
+ * http://bugzilla.maptools.org/show_bug.cgi?id=2604
|
|
+ * What appends in that case is that the bitspersample is 1 and
|
|
+ * a TransferFunction is set. The size of the TransferFunction
|
|
+ * depends on 1<<bitspersample. So if we increase it, an access
|
|
+ * out of the buffer will happen at directory flushing.
|
|
+ * Another option would be to clear those targs.
|
|
+ */
|
|
+ td->td_bitspersample = 8;
|
|
+ td->td_sampleformat = SAMPLEFORMAT_UINT;
|
|
+ }
|
|
}
|
|
|
|
static void
|
|
--
|
|
2.11.0
|
|
|