Bug 810551 (CVE-2012-2113) - CVE-2012-2113 libtiff: integer overflow in tiff2pdf leading to heap-buffer overflow when reading a tiled tiff file
Summary: CVE-2012-2113 libtiff: integer overflow in tiff2pdf leading to heap-buffer ov...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2012-2113
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 832866 835746 835747 835748 835749
Blocks: 803079
TreeView+ depends on / blocked
 
Reported: 2012-04-06 16:03 UTC by Karel Volný
Modified: 2023-05-13 02:01 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-31 17:35:57 UTC
Embargoed:


Attachments (Terms of Use)
I am not totally familiar with libtiff code, but this patch seems to work and does not produce any visible regressions (526 bytes, patch)
2012-04-09 06:47 UTC, Huzaifa S. Sidhpurwala
no flags Details | Diff
patch for uint32 vs tsize_t problems in libtiff 3.9 (5.02 KB, patch)
2012-04-17 20:50 UTC, Tom Lane
no flags Details | Diff
patch for lack of overflow checking in tiff2pdf (3.9) (8.96 KB, patch)
2012-04-17 20:52 UTC, Tom Lane
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:1054 0 normal SHIPPED_LIVE Important: libtiff security update 2012-07-03 13:29:13 UTC

Description Karel Volný 2012-04-06 16:03:58 UTC
Description of problem:

Version-Release number of selected component (if applicable):
libtiff-3.9.4-5.el6_2

How reproducible:
always

Steps to Reproduce:
1. tiff2pdf poc.tif
(where poc.tif is the file provided for testing CVE-2012-1173)

  
Actual results:
# tiff2pdf poc.tif 
II*%PDF-1.1 
%����
1 0 obj
<< 
/Type /Catalog 
/Pages 3 0 R 
>>
endobj
2 0 obj
<< 
/CreationDate (D:20120406113719)
/ModDate (D:20120406113719)
/Producer (libtiff / tiff2pdf - 20100615)
>> 
endobj
3 0 obj
<< 
/Type /Pages 
/Kids [ 4 0 R ] 
/Count 1 
>> 
endobj
4 0 obj
<<
/Type /Page 
/Parent 3 0 R 
/MediaBox [0.0000 0.0000 192.0000 145.6800] 
/Contents 5 0 R 
/Resources << 
/XObject <<
/Im1_1 7 0 R /Im1_2 9 0 R /Im1_3 11 0 R >>
/ProcSet [ /ImageC ]
>>
>>
endobj
5 0 obj
<< 
/Length 6 0 R 
 >>
stream
q  192.0000 0.0000 0.0000 61.4400 0.0000 84.2400 cm /Im1_1 Do Q
q  192.0000 0.0000 0.0000 61.4400 0.0000 22.8000 cm /Im1_2 Do Q
q  192.0000 0.0000 0.0000 22.8000 0.0000 0.0000 cm /Im1_3 Do Q

endstream
endobj
6 0 obj
191
endobj
7 0 obj
<< 
/Length 8 0 R 
/Type /XObject 
/Subtype /Image 
/Name /Im1_1
/Width 800
/Height 256
/BitsPerComponent 8
/ColorSpace /DeviceRGB 
 >>
stream
Segmentation fault (core dumped)

Expected results:
(some sane error message, no segfault)

Additional info:
This affects also RHEL5.

Comment 4 Huzaifa S. Sidhpurwala 2012-04-09 05:59:17 UTC
Here is some analysis of this issue:

When the tiff file is read in tif_dirread.c in function TIFFReadDirectory() the following code snippet is used:

        if (isTiled(tif)) {
                tif->tif_tilesize = TIFFTileSize(tif);

TIFFTileSize() calls TIFFVTileSize(), here the following multiplications occurs:


tilesize = multiply(tif, nrows, TIFFTileRowSize(tif),
                                    "TIFFVTileSize");
In the case of this repro, this makes tilesize as 2147483648, and then later

        return ((tsize_t)
            multiply(tif, tilesize, td->td_tiledepth, "TIFFVTileSize"));

Here td->td_tiledepth = -1, this makes tilesize as -2147483648, which is assigned to tif->tif_tilesize

Later when the tile is read via TIFFReadEncodedTile(), it calls DumpModeDecode() with cc = -2147483648, which inturn calls _TIFFmemcpy() which is a wrapper around mempcy and the size of in this case is -2147483648. This results in a buffer overflow and libtiff crashes.

Comment 5 Huzaifa S. Sidhpurwala 2012-04-09 06:08:55 UTC
So to summarise the above, this is essentially a type-conversion issue, leading to a heap-buffer overflow.

multiply() return a uint32, but tilesize is tsize_t which is int32, in our case this results in a positive integer being cast as negative.

Comment 6 Huzaifa S. Sidhpurwala 2012-04-09 06:47:37 UTC
Created attachment 576121 [details]
I am not totally familiar with libtiff code, but this patch seems to work and does not produce any visible regressions

Comment 7 Huzaifa S. Sidhpurwala 2012-04-09 06:53:35 UTC
Tom,

Hi, can you verify the above analysis and patches, also we need to send this upstream. Thanks.

Comment 8 Tom Lane 2012-04-11 16:18:41 UTC
I talked to upstream and they don't seem to have any better ideas than what I mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=803078#c6, viz adding checks in TIFFVTileSize and TIFFVStripSize for negative result.  So I'll push forward on that.  t2p_read_tiff_size needs work too.

Comment 10 Huzaifa S. Sidhpurwala 2012-04-17 04:30:46 UTC
Tom,

ping, any news from upstream about this?

Comment 11 Tom Lane 2012-04-17 20:50:50 UTC
Created attachment 578148 [details]
patch for uint32 vs tsize_t problems in libtiff 3.9

Comment 12 Tom Lane 2012-04-17 20:52:01 UTC
Created attachment 578149 [details]
patch for lack of overflow checking in tiff2pdf (3.9)

Comment 13 Tom Lane 2012-04-17 20:59:29 UTC
I have written and tested patches for the two issues we are dealing with here.  I think that we should actually treat them as two separate issues (two CVEs), because a look into the source code shows that the tsize_t problem is already fixed by upstream in libtiff 4.0.x.  So the first one only applies to 3.x releases, while the second is still applicable to 4.0.

I also notice that upstream's handling of the first matter in 4.0 is such that they will reject negative signed values for strip/tile sizes, which means that they have already accepted the limitation of buffer sizes not larger than 2GB on 32-bit machines.  So that makes me less concerned about back-patching a similar limitation into 3.x.

I need to adjust the tiff2pdf patch for the 4.0 code base and then send all three patches upstream; I will ask them about embargo dates when I do that (probably tomorrow).  We will also have a bit of work to do to back-port these patches into older 3.x releases, so there's a bit of work to do yet before we're ready anyhow.

Comment 14 Huzaifa S. Sidhpurwala 2012-04-18 05:19:18 UTC
Splitting the CVEs here:

CVE-2012-2088: This is for the type conversion flaw, which affects 3.x, but is fixed in upstream 4.0

CVE-2012-2113: This one is for integer overflow in tiff2pdf, which affects all versions.

Comment 22 Huzaifa S. Sidhpurwala 2012-06-18 04:28:35 UTC
(In reply to comment #14)
> Splitting the CVEs here:
> 
> CVE-2012-2088: This is for the type conversion flaw, which affects 3.x, but
> is fixed in upstream 4.0
> 
> CVE-2012-2113: This one is for integer overflow in tiff2pdf, which affects
> all versions.

Based on the above, it makes more sense to split the bugs as well, since these issues are essentially different.

This bug is going to be used for CVE-2012-2113

Comment 24 Huzaifa S. Sidhpurwala 2012-06-18 04:58:56 UTC
Created libtiff tracking bugs for this issue

Affects: fedora-all [bug 832866]

Comment 29 errata-xmlrpc 2012-07-03 09:30:27 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2012:1054 https://rhn.redhat.com/errata/RHSA-2012-1054.html

Comment 30 Fedora Update System 2012-07-15 21:25:39 UTC
libtiff-3.9.6-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 31 Fedora Update System 2012-07-15 21:26:47 UTC
libtiff-3.9.6-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Mark J. Cox 2012-08-22 10:20:21 UTC
Acknowledgement:

This issue was found by Karel Volný of Red Hat Quality Engineering.


Note You need to log in before you can comment on or make changes to this bug.