Heap-based buffer overflow in tifojpeg.c in the OJPEG decoder in LibTIFF before 3.9.5 allows remote attackers to execute arbitrary code via a crafted TIFF file.
The OJPEGPostDecode function in tifojpeg.c in LibTIFF 3.9.0 and 3.9.2, as used in tiff2ps, allows remote attackers to cause a denial of service (assertion failure and application exit) via a crafted TIFF image, related to "downsampled OJPEG input."
The TIFFVStripSize function in tifstrip.c in LibTIFF 3.9.0 and 3.9.2 makes incorrect calls to the TIFFGetField function, which allows remote attackers to cause a denial of service (application crash) via a crafted TIFF image, related to "downsampled OJPEG input" and possibly related to a compiler optimization that triggers a divide-by-zero error.
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."
LibTIFF 3.9.4 and earlier does not properly handle an invalid tdstripbytecount 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.
The TIFFExtractData macro in LibTIFF before 3.9.4 does not properly handle unknown tag types in TIFF directory entries, which allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted TIFF file.
Common Vulnerabilities and Exposures assigned an identifier CVE-2010-2443 to the following vulnerability:
Unspecified vulnerability in LibTIFF before 3.9.3 allows remote attackers to cause a denial of service (application crash) via an OJPEG image with undefined strip offsets.
References: http://www.remotesensing.org/libtiff/v3.9.3.html
A flaw was found in a way libtiff handled vertically flipped (i.e. with negative toskew) images on 64bit platforms. Numeric computation used to calculate buffer pointer was done in the way that incorrectly extended from 32bit type to 64bit, resulting in out-of-bounds writes.
For more details, refer to following bugs: http://bugzilla.maptools.org/showbug.cgi?id=2207 https://bugzilla.redhat.com/showbug.cgi?id=583081
Integer overflow in the TIFFroundup macro in LibTIFF before 3.9.3 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted TIFF file that triggers a buffer overflow.
A flaw was reported in libtiff's thunder decoder. The thunder decoder assumes 4bits per pixel, but if a file has bitpersample set to a smaller value, or defaulted (1) then the allocated strip buffer will be too small, and a heap-based buffer overlow may occur. This could be used to crash an application linked to libtiff, or execute arbitrary code with the privileges of the application opening a malicious TIFF file.
A stack-based buffer overflow was found in the way libtiff handled DOTRANGE tags. An attacker could use this flaw to create a specially-crafted TIFF file that, when opened, would cause an application linked against libtiff to crash or, possibly, execute arbitrary code.
This issue is fixed in libtiff-4.0.2
Description of problem:
Version-Release number of selected component (if applicable): libtiff-3.9.4-5.el62
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 << /Im11 7 0 R /Im12 9 0 R /Im13 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 /Im11 Do Q q 192.0000 0.0000 0.0000 61.4400 0.0000 22.8000 cm /Im12 Do Q q 192.0000 0.0000 0.0000 22.8000 0.0000 0.0000 cm /Im13 Do Q
endstream endobj 6 0 obj 191 endobj 7 0 obj << /Length 8 0 R /Type /XObject /Subtype /Image /Name /Im11 /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.
A type-conversion flaw leading to a heap-based buffer overflow was found in the way libtiff reads certain tiled tiff files. An attacker could create a specially-crafted TIFF image that, when opened, could cause an application using libtiff to crash or, possibly, execute arbitrary code with the privileges of the user running the application.
This issue does affects only version 3.x, but is fixed in upstream 4.x
This bug has been split from: bug 810551
A possible heap-based buffer overflow flaw was found in the readgifimage() function in gif2tiff, a tool to convert GIF images to TIFF. A remote attacker could provide a specially-crafted GIF file that, when processed by gif2tiff, would cause gif2tiff to crash or, potentially, execute arbitrary code with the privileges of the user running gif2tiff.
An OOB Write was found in the LZW decompressor used in gif2tiff, a tool to convert GIF images to TIFF. A remote attacker could provide a specially-crafted GIF file that, when processed by gif2tiff, would cause gif2tiff to crash or, potentially, execute arbitrary code with the privileges of the user running gif2tiff.