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.
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.
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.
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
Tom, Hi, can you verify the above analysis and patches, also we need to send this upstream. Thanks.
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.
Tom, ping, any news from upstream about this?
Created attachment 578148 [details] patch for uint32 vs tsize_t problems in libtiff 3.9
Created attachment 578149 [details] patch for lack of overflow checking in tiff2pdf (3.9)
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.
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.
(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
Created libtiff tracking bugs for this issue Affects: fedora-all [bug 832866]
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
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.
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.
Acknowledgement: This issue was found by Karel Volný of Red Hat Quality Engineering.