Bug 810551 (CVE-2012-2113)
| Summary: | CVE-2012-2113 libtiff: integer overflow in tiff2pdf leading to heap-buffer overflow when reading a tiled tiff file | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Karel Volný <kvolny> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | jlieskov, jrusnack, jscotka, mjc, rsawhill, security-response-team, tgl |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-07-31 17:35:57 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 832866, 835746, 835747, 835748, 835749 | ||
| Bug Blocks: | 803079 | ||
| Attachments: | |||
|
Description
Karel Volný
2012-04-06 16:03:58 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.
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. |