Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Apr 2012 15:58:45 +0400
From: Solar Designer <>
Cc: Frank Warmerdam <>,,
	M Hjkoko <>
Subject: libtiff tif_getimage.c integer overflow leading to heap overwrite when parsing certain TIFF files (ZDI-CAN-1221 / CVE-2012-1173)


I realize that it is not great to post this on a weekend.  The issue was
technically made public on April 4 (Wednesday), however unfortunately
the folks on distros list who were actually involved in its handling
have failed to post about it to oss-security in time - so I feel I had
to substitute for them.  Delaying this further till Monday felt even
worse since the issue was already public.

This issue was tracked as ZDI-CAN-1221 / CVE-2012-1173.

Vincent Danen summarized the issue as follows (in a comment on Red Hat
bug 803078):

"A flaw was found in the way that LibTIFF attempted to allocate space for a tile
within a TIFF image file.  When calculating the size for a buffer, LibTIFF
performs a multiply that can cause an integer overflow.  After allocation,
LibTIFF will initialize the buffer with the tile data, which can cause code
execution under the context of the application using LibTIFF, and with the
calling user's permissions."

Upstream Bugzilla entry, which now has patches attached to it (thank
you, Frank):

Looking at the patches, I actually see two instances of integer
multiplication before heap buffer allocation patched to use
TIFFSafeMultiply(): one of them is for tilesize, the other for
stripsize.  I assume CVE-2012-1173 applies to both issues at once.

So far, I am only aware of Mandrake having announced this via
MDVSA-2012:054 published on April 5.  Some other distros appear to have
patched the issue or/and have made changelog/bug entries relating to it
public without issuing an advisory yet.

On April 6, the Red Hat bug entry:

got an extra comment posted to it by Karel Volny with what appears to be
an extra bug to patch (non-security?)  It also references not-public-yet
RH bug 810551 (I have no idea what that one is - I did say I was not the
best person to post this).

The timeline appears to be as follows:

2011-05-12 or earlier: bug discovered and reported to ZDI by Alexander Gavrun

2011-05-12: bug reported by ZDI to libtiff upstream (Frank Warmerdam)

2012-03-09: M Hjkoko creates the bug entry and thereby reminds
upstream of the issue

2012-03-12: M Hjkoko alerts the distros list that there's an upcoming
libtiff issue listed at
No detail is included, and all info posted to the distros list by this
point is publicly available, hence the distros list embargo timer is not
ticking yet.  (Maybe we should have posted the same info to oss-security
at that time, though.)

2012-03-13: CVE-2012-1173 is assigned by Red Hat.

2012-03-21: Red Hat folks post to distros list (in response to inquiry
by a non-Red Hat list member) actual detail on the issue, which they had
obtained from ZDI in the previous few days.  Since non-public info got
to the distros list at this point, the embargo timer started ticking.
Unfortunately, this aspect was not understood and thus was not
coordinated with ZDI and upstream prior to the distros list posting.

2012-03-xx: apparently, Tom Lane at Red Hat works on the fixes.
(Current upstream patches credit Tom for the fixes.)

2012-03-27 - 2012-03-30: Discussion regarding embargo time and how we
must make the issue public no later than 2012-04-04 (14 days since
2012-03-21).  Luckily, ZDI was OK with this, and Frank even proposed
making the issue public on 2012-04-01 (thanks!), but then 2012-04-04 was
quickly agreed upon as the coordinated release date.

2012-04-04: The issue is supposed to be made public.

2012-04-05: MDVSA-2012:054 is published.

2012-04-06: Upstream patches are posted at

2012-04-06: Karel Volny's comment is posted at
(might require further work)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.