Bug 276988 (CVE-2009-2347) – <media-libs/tiff-3.8.2-r8 tools heap-based buffer overflow (CVE-2009-2347)

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Robert Buchholz (RETIRED) 2009-07-07 23:46:49 UTC]

** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

Libtiff software package includes a library, libtiff, for reading and  
writing TIFF (/Tag Image File Format/), a small collection of tools (such 
as tiff2pdf, tiff2ps, tiff2rgba, rgb2ycbcr) for doing simple manipulations 
of TIFF images on UNIX systems. I find two tools tiff2rgba and 
rgb2ycbcr suffer from integer overflow vulnerabilities. The two integer 
overflow vulnerabilities could cause heap overflows and may result in 
arbitrary code execution.

tiff2rgba is used to convert a TIFF image to RGBA color space and  
rgb2ycbcr is used to convert non-YCbCr TIFF images to a YCbCr TIFF image.
 
For tiff2rgba, the vulnerability is in function cvt_whole_image() in  
tiff-3.8.2/tools/tiff2rgba.c.

The vulnerable code is shown as below. TIFFGetField is used to read the  
specified field from an input tiff image. Both width (line 332) and  
height (line 333) originate from the input image. cvt_whole_image() does 
not properly check width and height so that width * height * sizeof 
(uint32) in line 338 could overflow. The overflowed value is used in 
memory allocation function, which causes an insufficient memory  
allocation. Heap overflow occurs when function TIFFReadRGBAImageOriented() 
in line 345 reads the actual image data to memory.

For rgb2ycbcr, the vulnerability is in function tiffcvt() in  
tiff-3.8.2/tools/rgb2ycbcr.c. Similar with the vulnerability discussed  
above, function tiffcvt() does not also check width and height read  
from input file (line 282, 283). Thus, width * height * sizeof (uint32) 
could overflow so that raster points to a smaller-than-expected buffer. 
Heap overflow occurs when function TIFFReadRGBAImage() in line 289 reads 
the actual image data to memory.

The vulnerability is reported by 
Tielei Wang, ICST-ERCIS (Engineering Research Center of Info Security, 
Institute of Computer Science & Technology, Peking University / China).

[Comment 1 Robert Buchholz (RETIRED) 2009-07-07 23:47:57 UTC]

I know we are stabling another version of tiff in bug 276339, but let's get the prestabling of another new version going on here. Please attach an ebuild applying the patch. Thanks!

[Comment 2 Robert Buchholz (RETIRED) 2009-07-07 23:48:42 UTC]

Created attachment 197131 [details, diff]
tiff-3.8.2-CVE-2009-2347.patch

Patch by Andrey Kiselev.

[Comment 3 Markus Meier 2009-07-08 21:47:05 UTC]

Created attachment 197267 [details]
tiff-3.8.2-r8.tar.bz2

here's a tarball with all the patches and -r8 ebuild, which applies tiff-3.8.2-CVE-2009-2347.patch (only difference to -r7).

[Comment 4 Robert Buchholz (RETIRED) 2009-07-08 23:17:01 UTC]

Arch Security Liaisons, please test the attached ebuild and report it stable on this bug:
=media-libs/tiff-3.8.2-r8
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"

CC'ing current Liaisons:
   alpha : armin76, klausman
   amd64 : keytoaster, tester
    hppa : jer
     ppc : josejx, ranger
   ppc64 : josejx, ranger
   sparc : fmccor
     x86 : fauli, maekke

[Comment 5 Ferris McCormick (RETIRED) 2009-07-09 12:10:48 UTC]

Looks good on sparc.

[Comment 6 Christian Faulhammer (RETIRED) 2009-07-09 12:27:44 UTC]

x86 ok.  Hey, there was just a stabilisation, that's 70 packages to recompile.

Don't forget to add the changes done in the main tree when importing the final -r8 revision.

[Comment 7 Jeroen Roovers (RETIRED) 2009-07-09 16:44:45 UTC]

HPPA is OK.

[Comment 8 Robert Buchholz (RETIRED) 2009-07-13 10:39:57 UTC]

Created attachment 197767 [details, diff]
tiff-3.8.2-CVE-2009-2347.patch

Tom Lane did additional analysis on the issue and sent in a revised patch:

The original patch missed two out of three places with the same bug in
tiff2rgba.  (I looked around for additional occurrences and didn't find any,
though I can't swear there are none.)  Also, I checked with Frank Warmerdam who
disapproved of letting the tools/ files use tiffiop.h, so the revised patch
does not use _TIFFCheckMalloc.  Some other cleanup too, mostly around being
careful if size_t is wider than 32 bits and not claiming that
possibly-perfectly-legal files are "malformed".

[Comment 9 Robert Buchholz (RETIRED) 2009-07-13 10:41:54 UTC]

given that only few arches responded and that disclosure is later today, let's stable this in-tree. Also, upstream has yet to approve the revised patch.

[Comment 10 Robert Buchholz (RETIRED) 2009-07-13 14:40:19 UTC]

public via https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-2347

please bump in the tree, and we'll do stabling there.

[Comment 11 Christian Faulhammer (RETIRED) 2009-07-14 15:18:52 UTC]

On behalf of maekke I bumped the ebuild with the updated patch.  Stable for x86 and ccing other arches.

[Comment 12 Jeroen Roovers (RETIRED) 2009-07-15 14:10:03 UTC]

Stable for HPPA.

[Comment 13 Raúl Porcel (RETIRED) 2009-07-15 14:18:04 UTC]

alpha/arm/ia64/m68k/s390/sh/sparc stable

[Comment 14 Alex Legler (RETIRED) 2009-07-15 19:21:46 UTC]

CVE-2009-2347 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2347):
  Multiple integer overflows in inter-color spaces conversion tools in
  libtiff 3.8 through 3.8.2, 3.9, and 4.0 allow context-dependent
  attackers to execute arbitrary code via a TIFF image with large (1)
  width and (2) height values, which triggers a heap-based buffer
  overflow in the (a) cvt_whole_image function in tiff2rgba and (b)
  tiffcvt function in rgb2ycbcr.

[Comment 15 nixnut (RETIRED) 2009-07-19 16:13:43 UTC]

ppc stable

[Comment 16 Brent Baude (RETIRED) 2009-07-26 12:43:13 UTC]

ppc64 done

[Comment 17 Markus Meier 2009-07-27 22:04:14 UTC]

amd64 stable, all arches done.

[Comment 18 Markus Meier 2009-07-27 22:05:05 UTC]

sorry about closing the bug...

[Comment 19 Alex Legler (RETIRED) 2009-08-05 13:20:45 UTC]

GLSA with bug 276339.

[Comment 20 Robert Buchholz (RETIRED) 2009-08-07 11:49:43 UTC]

GLSA 200908-03