Bug 444079 (CVE-2008-1586)

Summary:	VUL-0: CVE-2008-1586: TIFF memory use denial-of-service
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Sebastian Krahmer <krahmer>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	RESOLVED FIXED	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	meissner, ro, security-team
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	openSUSE 11.0
Whiteboard:	CVE-2008-1586: CVSS v2 Base Score: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C)
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	the attachment from the mail

Description Sebastian Krahmer 2008-11-12 09:27:32 UTC

From: Geoff Keating <geoffk@apple.com>
To: vendor-sec@lst.de
Date: Tue, 11 Nov 2008 16:00:38 -0800
Cc: Frank Warmerdam <warmerdam@pobox.com>,
        Andrey Kiselev <dron@ak4719.spb.edu>

We've found that a memory exhaustion issue exists in the handling of
TIFF images. Viewing a maliciously crafted TIFF image may lead to
memory exhaustion, which on iPhone causes a kernel watchdog timeout
and then a device reset.  We plan to fix the issue on iPhone by
limiting the amount of memory that can be allocated as part of opening
a TIFF image.

The issue here is that when a TIFF file specifies a huge number of
strips or tiles, the TIFF reader will allocate space for all of those
strips, even if there isn't that much memory available.  It will do
this even if the file isn't anywhere close to being big enough to
actually have all those strips.  This occurs on all platforms.

We have assigned this issue, as it applies to iPhone, CVE-2008-1586.

We will credit Sergio Alvarez for reporting this issue.

I wrote a simple example that demonstrates this with stock libTIFF
(but not if you just open it on iPhone), which I attach as
CVE-2008-1586.zip.

Comment 1 Sebastian Krahmer 2008-11-12 09:29:37 UTC

Created attachment 251527 [details]
the attachment from the mail

Comment 2 Vladimir Nadvornik 2008-11-19 15:42:42 UTC

The test image causes an endless loop. This patch fixes it. I did not notice any other problem. 
Max. size of a tiff image is 4GB. Today machines should handle this so I don't think there should be any further limitation.


--- libtiff/tif_dirread.c
+++ libtiff/tif_dirread.c
@@ -870,7 +870,7 @@

        register TIFFDirEntry *dp;
        register TIFFDirectory *td = &tif->tif_dir;
-       uint16 i;
+       uint32 i;

        if (td->td_stripbytecount)
                _TIFFfree(td->td_stripbytecount);

Comment 3 Sebastian Krahmer 2009-02-03 08:16:04 UTC

ping. which dists need updates, or will STABLE suffice?

Comment 4 Vladimir Nadvornik 2009-02-04 13:49:38 UTC

Sorry for the delay.

The bug is present in libtiff 3.8.2 which is in 10.3 - 11.1
The older libtiff versions on SLES9 and 10 handle the image correctly (as a very large image that is truncated)

Comment 5 Swamp Workflow Management 2009-02-04 14:05:21 UTC

The SWAMPID for this issue is 22388.
Please submit the patch and patchinfo file using this ID.
(https://swamp.suse.de/webswamp/wf/22388)

Comment 6 Vladimir Nadvornik 2009-02-04 15:12:02 UTC

submitted for 10.3 - 11.1 and sle11

Comment 8 Ludwig Nussel 2009-02-12 11:24:43 UTC

the crd in swamp was wrong. it actually is already public

Comment 9 Swamp Workflow Management 2009-02-12 11:26:00 UTC

Update released for: libtiff-devel, libtiff3, tiff
Products:
openSUSE 10.3 (i386, ppc, ppc64, x86_64)
openSUSE 11.0 (debug, i386, ppc, ppc64, x86_64)
openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64)

Comment 10 Thomas Biege 2009-10-14 01:43:32 UTC

CVE-2008-1586: CVSS v2 Base Score: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C)