The libtiff changelog at $URL includes several security related fixes, including:
# libtiff/tif_jpeg.c, libtiff/tif_strip.c: apply patch for CVE-2010-3087 per bug http://bugzilla.maptools.org/show_bug.cgi?id=2140
# libtiff/tif_color.c: prevent crash in handling bad TIFFs resolves CVE-2010-2595 http://bugzilla.maptools.org/show_bug.cgi?id=2208
# libtiff/tif_fax3.h: Protect against a fax VL(n) codeword commanding a move left. Without this, a malicious input file can generate an indefinitely large series of runs without a0 ever reaching the right margin, thus overrunning our buffer of run lengths. Per CVE-2011-0192. This is a modified version of a patch proposed by Drew Yao of Apple Product Security. It adds an unexpected() report, and disallows the equality case, since emitting a run without increasing a0 still allows buffer overrun.
# libtiff/tif_thunder.c: Correct potential buffer overflow with thunder encoded files with wrong bitspersample set. The libtiff development team would like to thank Marin Barbella and TippingPoint's Zero Day Initiative for reporting this vulnerability (ZDI-CAN-1004, CVE-2011-1167). http://bugzilla.maptools.org/show_bug.cgi?id=2300
# libtiff/tif_ojpeg.c: fix buffer overflow on problem data http://bugzilla.maptools.org/show_bug.cgi?id=1999
@graphics, @nerdboy, can we move forward with stabilizing 3.9.5? Thanks.
Heap-based buffer overflow in tif_ojpeg.c in the OJPEG decoder in LibTIFF
before 3.9.5 allows remote attackers to execute arbitrary code via a crafted
LibTIFF before 3.9.2-5.2.1 in SUSE openSUSE 11.3 allows remote attackers to
cause a denial of service (memory corruption) or possibly execute arbitrary
code via a crafted TIFF image.
The TIFFYCbCrtoRGB function in LibTIFF 3.9.0 and 3.9.2, as used in
ImageMagick, does not properly handle invalid ReferenceBlackWhite values,
which allows remote attackers to cause a denial of service (application
crash) via a crafted TIFF image that triggers an array index error, related
to "downsampled OJPEG input."
Maintainer timed out.
Arches, please test and mark stable:
target KEYWORDS : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Builds fine on x86. Tested with shutterbug rdep and converted the tiff image to pdf with tiff2pdf. Please mark stable for x86.
Archtested on x86: Everything fine
x86 stable, thanks Myckel and JD!
amd64 done. Thanks Agostino
Stable for HPPA.
Thanks, everyone. Added to existing GLSA request.
LibTIFF 3.9.4 and earlier does not properly handle an invalid
td_stripbytecount field, which allows remote attackers to cause a denial of
service (NULL pointer dereference and application crash) via a crafted TIFF
file, a different vulnerability than CVE-2010-2443.
Integer overflow in the ReadDirectory function in tiffdump.c in tiffdump in
LibTIFF before 3.9.5 allows remote attackers to cause a denial of service
(application crash) or possibly have unspecified other impact via a crafted
TIFF file containing a directory data structure with many directory entries.
This issue was resolved and addressed in
GLSA 201209-02 at http://security.gentoo.org/glsa/glsa-201209-02.xml
by GLSA coordinator Sean Amoss (ackle).