Bugzilla – Bug 612787
VUL-0: CVE-2010-2067: libtiff SubjectDistance tag processing buffer overflow
Last modified: 2015-07-16 07:28:39 UTC
Date: Tue, 8 Jun 2010 15:18:11 +0200 From: Tomas Hoger <thoger@redhat.com> To: Vendor-Sec <vendor-sec@lst.de> Cc: vendor-disclosure@idefense.com, warmerdam@pobox.com Subject: [vendor-sec] libtiff SubjectDistance tag processing buffer overflow (iDefense V-bkoqqi7alh) Hi! Forwarding iDefense libtiff vulnerability report. --- snip --- Vulnerability Description ------------------------- Remote exploitation of a stack buffer overflow vulnerability in version 3.9.2 of LibTIFF, as included in various vendors' operating system distributions, could allow an attacker to execute arbitrary code with the privileges of the current user. libTIFF is a free and popular image library that provides support for displaying and manipulating Tag Image File Format (TIFF) image data. This library is used by numerous applications and is included in various vendor operating system distributions. This vulnerability is due to insufficient bounds checking when copying data into a stack allocated buffer. During the processing of a certain EXIF tag a fixed sized stack buffer is used as a destination location for a memory copy. This memory copy can cause the bounds of a stack buffer to be overflown and this condition may lead to arbitrary code execution. Analysis -------- Exploitation of this vulnerability results in the execution of arbitrary code with the privileges of the current user. In order to exploit this vulnerability, a user must load a web page containing a specially crafted TIFF image. An attacker typically accomplishes this via social engineering or injecting content into compromised, trusted sites. Typical social engineering attacks will pass URLs as part of instant messages or electronic mail. Successful exploitation of this vulnerability may depend on exploit mitigation that is used by the target platform. For a platform with no stack based exploit mitigation, this vulnerability can be trivially exploited by overwriting a saved instruction pointer value on the stack. iDefense considers this vulnerability to be of HIGH severity due to the possibility of arbitrary code execution with minimal user interaction. Detection --------- iDefense has confirmed the existence of this vulnerability in version 3.9.2 of libTIFF. Previous versions are not affected. iDefense believes that multiple vendors may be affected by this issue. All platforms that include libTIFF version 3.9.2 are affected by this vulnerability, including Fedora Core 13 and Ubuntu 10.04. iDefense tested the exploitation of this vulnerability under Ubuntu 8.04. Ubuntu does not ship with libTIFF 3.9.2 installed by default. --- snip --- Attached is reproducer and upstream fix provided by Frank Warmerdam. It seems to make most sense to address this at the same time as the other issue that is currently discussed on the vendor-sec list. Would anyone object to pushing CRD for that issue by one week to Jun16 and use the same date for this issue too? -- Tomas Hoger / Red Hat Security Response Team
Created attachment 368040 [details] attached patch from the mail ...
Created attachment 368041 [details] attached exploit from mail ...
CVE-2010-2067 CRD currently not set as upstream is busy
(from kees cook) Also note that credit for the discovery should be to Dan Rosenberg.
Am I supposed to test this fix somehow? If yes, please let me know the way to reproduce this, tiff2rgba and tiff2pdf for example seem to behave normally on the testcase with the unpatched library.
Hm, I wasn't able to reproduce it too. (tiff-3.8.2-145.4.1.i586) I will ask the other vendors...
(In reply to comment #6) > Hm, I wasn't able to reproduce it too. (tiff-3.8.2-145.4.1.i586) I will ask the > other vendors... 3.8.2 isn't affected as stated in comment 0. Please try 3.9.2 from Factory.
Libtiff works fine here with 3.9.2 too and I got no response from other vendors so far.
(In reply to comment #8) > Libtiff works fine here with 3.9.2 too and I got no response from other vendors > so far. From comment 0: " ... exploit this vulnerability, a user must load a web page containing a specially crafted TIFF image. An attacker typically accomplishes this ... " May be that there is some way to really break it by using some function which is not used by typical tiff tools? Would be possible to ask Thomas Hoger which steps leads to exploit?
According to private mail with Petr, there is a new issue as posted by Dan Rosenberg: Date: Tue, 29 Jun 2010 08:05:25 -0400 From: Dan Rosenberg <dan.j.rosenberg@gmail.com> To: oss-security@lists.openwall.com Cc: Tomas Hoger <thoger@redhat.com>, Josh Bressers <bressers@redhat.com>, coley <coley@mitre.org> Subject: Re: [oss-security] CVE requests: LibTIFF On request, I'm re-posting the issues which I think actually deserve CVE ids. The following three issues reliably crash libtiff in the general case of doing initial parsing to view an image: 1. Out-of-bounds read in TIFFExtractData() may result in application crash. Revision 1.92.2.9 of libtiff/tif_dirread.c added code for ensuring valid type information for each TIFF directory entry. Prior to this fix, unknown tag types would result in an out-of-bounds array index in TIFFExtractData() on any code path using this macro. Ubuntu security backported this fix as debian/patches/fix-unknown-tags.patch because in discussion with them, I identified the patch as a fix for this issue. I discovered this issue and disclosed it to iDefense Labs along with the SubjectDistance overflow, but they did not share details of this with downstream vendors (which was the source of my confusion surrounding knowledge of the issue). It seems that it was actually fixed in 3.9.4 inadvertently as a result of fixing another unrelated problem, and my description of it here can be considered the first disclosure of the issue, which affects all versions 3.x <= 3.9.2.
(In reply to comment #9) > May be that there is some way to really break it by using some function which > is not used by typical tiff tools? Would be possible to ask Thomas Hoger which > steps leads to exploit? According to Thomas Hoger tiffinfo triggers the bug with 3.9.2
this one really is the worst of all currently open libtiff issues. this one needs to be fixed for 11.3.
(In reply to comment #11) > According to Thomas Hoger tiffinfo triggers the bug with 3.9.2 Confirmed.
Sadly debian/patches/fix-unknown-tags.patch didn't fix the problem for me, so I have to investigate it further.
(In reply to comment #14) > Sadly debian/patches/fix-unknown-tags.patch didn't fix the problem for me, so I > have to investigate it further. Well that's because debian/patches/fix-unknown-tags.patch evidently fixes another issue :-). Problem exhibited by tiffinfo exploit.tif is fixed by debian/patches/CVE-2010-2067.patch :-). Don't know for what is debian/patches/fix-unknown-tags.patch used for, but please open new bugreport for this, if you think it is necessary to have it. Note that this is backported to 3.8.2 by debian yet.
yeah, comment #10 is unrelated and confusing. This bug is only about a stack overflow in TIFFFetchSubjectDistance ie CVE-2010-2067. I've posted a summary of all issues here: https://bugzilla.novell.com/show_bug.cgi?id=612879#c27 The unkown-tags thingy is a simple crash only. no need for security update atm.
Okay. 3.8.2 doesn't seem to be affected by CVE-2010-2067, so 11.3 and Factory only.
Against which project I should send a request? openSUSE:11.3? openSUSE:11.3:Update:Test?
either will do but the latter is formally more correct I guess
For 11.3: Request #42842: submit: home:pgajdos:branches:openSUSE:11.3/tiff(r3) -> openSUSE:11.3:Update:Test/tiff Message: - fixed SubjectDistance tag processing buffer overflow (CVE-2010-2067) [bnc#bnc612787] * dirread-oob-unknown-tags.patch State: new 2010-07-12T16:30:02 pgajdos Comment: None
Fro Factory: Request #42845: submit: graphics/tiff(r21) -> openSUSE:Factory/tiff Message: - updated to 3.9.4: fixes CVE-2010-2065 -- obsoletes * integer-overflow.patch * NULL-deref.patch - fixes CVE-2010-2067 State: new 2010-07-12T16:43:15 pgajdos Comment: None
released