A flaw was found in Libtiff. This vulnerability is a "write-what-where" condition, triggered when the library processes a specially crafted TIFF image file.

The issue happens when decoding Pixarlog codec images with PIXARLOGDATAFMT8BITABGR output format and stride = 3 . The decoder writes 4 output bytes per 3 decoded samples (synthetic alpha byte) but advances the output cursor by 3 bytes. This mismatch causes a linear heap based buffer-overflow of approx. width bytes per scan line. For every 4-bytes in the overflow, the first is always 0x00 while the others are controlled. The overflow happens on a user allocated buffer, but according to the docs (TIFFReadScnaline.rst) the user is supposed to allocate a buffer of this TIFFScanlineSize(t) , which will return the incorrect size. The bug can be pinpointed to two locations in libtiff/tifpixarlog.c - the horizontalAccumulate8abgr function (3->4 byte expansion), and PixarLogDecode which updates the output pointer. RCA PixarLogDecode dispatches on sp->userdatafmt: case PIXARLOGDATAFMT8BITABGR: horizontalAccumulate8abgr(up, llen, sp->stride, (unsigned char )op, sp->ToLinear8); op += llen sizeof(unsigned char); // <-- WRONG for stride=3 break; horizontalAccumulate8abgr with stride == 3 emits 4 bytes per input triplet: if (stride == 3) { op[0] = 0; op[1] = t1; op[2] = t2; op[3] = t3; / 4 bytes written / n -= 3; while (n > 0) { n -= 3; wp += 3; op += 4; / advance 4 per triplet / op[0] = 0; op[1] = …; op[2] = …; op[3] = …; } } So for llen = stride width = 3 W input samples the function writes (llen / 3) 4 = 4 W bytes. PixarLogDecode then advances op by only llen = 3 W. The next iteration starts W bytes before the position where the previous write ended, and on the final iteration the writes extend W bytes past the end of the buffer the caller allocated from TIFFScanlineSize (which is W stride 1 = 3 W bytes for this configuration). Reachability Any application that selects PIXARLOGDATAFMT8BITABGR via TIFFSetField(tif, TIFFTAGPIXARLOGDATAFMT, PIXARLOGDATAFMT8BITABGR) and then reads a PixarLog-compressed TIFF with SamplesPerPixel == 3 is affected. The standard format picker in TIFFRGBAImageBegin does not select 8BITABGR (it picks 8BIT, 16BIT or FLOAT), so TIFFReadRGBAImage is not directly affected. PoC I attached a c program, that when executed produces a file that will overflow a heap buffer by 64 bytes. To verify I compiled it along with ASan-enabled libtiff, and got: $ gcc -fsanitize=address -g -O1 pixarlogheapoverflowpoc.c \ -I$LIBTIFF/libtiff -I$BUILD/libtiff \ -L$BUILD/libtiff -ltiff -Wl,-rpath,$BUILD/libtiff -o poc $ ./poc ================================================================= ==...==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x… at pc 0x… WRITE of size 1 at 0x… thread T0 #0 horizontalAccumulate8abgr libtiff/tifpixarlog.c:470 #1 PixarLogDecode libtiff/tifpixarlog.c:980 #2 TIFFReadScanline libtiff/tifread.c:465 #3 main pocpixarlog8bitabgr.c:31 0 bytes to the right of 192-byte region The 192-byte region is the caller's TIFFScanlineSize-sized buffer (W 3 = 192). The decoder writes 256 bytes ((W 3 / 3) 4 = 256) per row, producing a 64-byte overflow per row. pixarlogheapoverflowpoc.c Fix I didn't open a PR for this fix, since I'm not sure how to make it confidential and I wanted the maintainer to review this issue first. If you want me to open the PR, lmk and I'll do it as instructed. I think that in order to fix, we need to correct the output pointer advancement in PixarLogDecode: case PIXARLOGDATAFMT8BITABGR: horizontalAccumulate8abgr(up, llen, sp->stride, (unsigned char )op, sp->ToLinear8); if (sp->stride == 3) op += (sizet)(llen / 3) 4; / 4 output bytes per triplet / else op += (sizet)llen sizeof(unsigned char); break; And also to somehow make TIFFScanlineSize return the correct size. We can maybe do this with introducing a codec ScanLinesize override that is checked in the function: / tifstrip.c — TIFFScanlineSize64 / if (tif->tifscanlinesizeoverride) return tif->tifscanlinesizeoverride(tif); // ...

An integer overflow in the libtiff rgb2ycbcr utility's cvtRaster() function when computing strip buffer sizes can result in an undersized heap allocation and subsequent heap-based buffer overflow during YCbCr conversion of a crafted TIFF image

An issue in libtiff 85f2ac8e0b01cb7db2bbecf4a3b891bdbef67938 allows an attacker to execute arbitrary code via the processcommandopts() function in tools/tiffcrop.c

An out-of-memory flaw was found in libtiff that could be triggered by passing a crafted tiff file to the TIFFRasterScanlineSize64() API. This flaw allows a remote attacker to cause a denial of service via a crafted input with a size smaller than 379 KB.

An out-of-memory problem was found in libtiff that could be triggered by passing a craft tiff file to TIFFRasterScanlineSize64() API. In this flaw a remote attackers could cause deny-of-services via a craft input (with size smaller than 379 KB).

Reference: https://gitlab.com/libtiff/libtiff/-/issues/621

Fixed at: https://gitlab.com/libtiff/libtiff/-/mergerequests/553 https://gitlab.com/libtiff/libtiff/-/commit/6791bff9f76c2a7f2f18c80b95c796e93fae6a34

A flaw was found in the libtiff library. A remote attacker could exploit a signed integer overflow vulnerability in the putcontig8bitYCbCr44tile function by providing a specially crafted TIFF file. This flaw can lead to an out-of-bounds heap write due to incorrect memory pointer calculations, potentially causing a denial of service (application crash) or arbitrary code execution.

A flaw was found in the libtiff library. A signed integer overflow exists in the putcontig8bitYCbCr44tile function (and potentially similar functions like putcontig8bitYCbCr42tile, putcontig8bitYCbCr22tile, and putcontig8bitYCbCr12tile) within tifgetimage.c. When processing a specially crafted TIFF file with an extremely large width and specific YCbCr subsampling, the calculation for the pointer progression variable (incr) can overflow the 32-bit signed integer boundary. This results in an incorrect negative progression of memory pointers, leading to an out-of-bounds heap write. An attacker could exploit this to cause a denial of service (application crash) or potentially execute arbitrary code.

Buffer Overflow vulnerability found in Libtiff V.4.0.7 allows a local attacker to cause a denial of service via the tiffcp function in tiffcp.c.

A vulnerability was found in the libtiff library. This security flaw causes a heap buffer overflow in extractContigSamples32bits, tiffcrop.c.

A vulnerability was found in the libtiff library. This flaw causes a heap buffer overflow issue via the TIFFTAGINKNAMES and TIFFTAGNUMBEROFINKS values.

Heap buffer overflow in extractContigSamples32bits, tiffcrop.c

https://gitlab.com/libtiff/libtiff/-/issues/464

heap-buffer-overflow in tiffcrop https://gitlab.com/libtiff/libtiff/-/issues/463

A vulnerability was found in LibTIFF. It has been classified as critical. This affects the function TIFFReadRGBATileExt of the file libtiff/tifgetimage.c. The manipulation leads to integer overflow. It is possible to initiate the attack remotely.

References: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137 https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be

A vulnerability was found in LibTIFF. It has been classified as critical. This affects the function TIFFReadRGBATileExt of the file libtiff/tifgetimage.c. The manipulation leads to integer overflow. It is possible to initiate the attack remotely.

References: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=53137 https://gitlab.com/libtiff/libtiff/-/commit/227500897dfb07fb7d27f7aa570050e62617e3be

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemcpy in libtiff/tifunix.c:346 when called from extractImageSection, tools/tiffcrop.c:6860, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemcpy in libtiff/tifunix.c:346 when called from extractImageSection, tools/tiffcrop.c:6860, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

References: https://gitlab.com/libtiff/libtiff/-/commit/236b7191f04c60d09ee836ae13b50f812c841047 https://gitlab.com/libtiff/libtiff/-/issues/411 https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3627.json

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemset in libtiff/tifunix.c:340 when called from processCropSelections, tools/tiffcrop.c:7619, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemset in libtiff/tifunix.c:340 when called from processCropSelections, tools/tiffcrop.c:7619, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

References: https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3626.json https://gitlab.com/libtiff/libtiff/-/issues/426 https://gitlab.com/libtiff/libtiff/-/commit/236b7191f04c60d09ee836ae13b50f812c841047

Multiple heap buffer overflows in tiffcrop.c utility in libtiff library Version 4.4.0 allows attacker to trigger unsafe or out of bounds memory access via crafted TIFF image file which could result into application crash, potential information disclosure or any other context-dependent impact

LibTIFF 4.4.0 has an out-of-bounds read in writeSingleSection in tools/tiffcrop.c:7345, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit e8131125.

Multiple heap buffer overflows in tiffcrop.c utility in libtiff library Version 4.4.0 allows attacker to trigger unsafe or out of bounds memory access via crafted TIFF image file which could result into application crash, potential information disclosure or any other context-dependent impact

References: https://gitlab.com/libtiff/libtiff/-/issues/386 https://gitlab.com/libtiff/libtiff/-/commit/bd94a9b383d8755a27b5a1bc27660b8ad10b094c https://gitlab.com/libtiff/libtiff/-/issues/381 https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3570.json

LibTIFF 4.4.0 has an out-of-bounds read in writeSingleSection in tools/tiffcrop.c:7345, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit e8131125.

References: https://gitlab.com/libtiff/libtiff/-/commit/e813112545942107551433d61afd16ac094ff246 https://gitlab.com/libtiff/libtiff/-/issues/398 https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3599.json

LibTIFF 4.4.0 has an out-of-bounds write in extractContigSamplesShifted24bits in tools/tiffcrop.c:3604, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit cfbb883b.

LibTIFF 4.4.0 has an out-of-bounds write in extractContigSamplesShifted24bits in tools/tiffcrop.c:3604, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit cfbb883b.

References: https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3598.json https://gitlab.com/libtiff/libtiff/-/issues/435 https://gitlab.com/libtiff/libtiff/-/commit/cfbb883bf6ea7bedcb04177cc4e52d304522fdff

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemcpy in libtiff/tifunix.c:346 when called from extractImageSection, tools/tiffcrop.c:6826, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

LibTIFF 4.4.0 has an out-of-bounds write in TIFFmemcpy in libtiff/tifunix.c:346 when called from extractImageSection, tools/tiffcrop.c:6826, allowing attackers to cause a denial-of-service via a crafted tiff file. For users that compile libtiff from sources, the fix is available with commit 236b7191.

References: https://gitlab.com/libtiff/libtiff/-/issues/413 https://gitlab.com/libtiff/libtiff/-/commit/236b7191f04c60d09ee836ae13b50f812c841047 https://gitlab.com/gitlab-org/cves/-/blob/master/2022/CVE-2022-3597.json

A memory leak flaw was found in Libtiff's tiffcrop utility. This issue occurs when tiffcrop operates on a TIFF image file, allowing an attacker to pass a crafted TIFF image file to tiffcrop utility, which causes this memory leak issue, resulting an application crash, eventually leading to a denial of service.

A vulnerability classified as problematic was found in libtiff 4.6.0. This vulnerability affects the function PSLvl2page of the file tools/tiff2ps.c of the component tiff2ps. The manipulation leads to null pointer dereference. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 6ba36f159fd396ad11bf6b7874554197736ecc8b. It is recommended to apply a patch to fix this issue. One of the maintainers explains, that "[t]his error only occurs if DEFERSTRILELOAD (defer-strile-load:BOOL=ON) or TIFFOpen( .. "rD") option is used."

A vulnerability was found in LibTIFF up to 4.7.0. It has been declared as critical. This vulnerability affects the function gethistogram of the file tools/tiffmedian.c. The manipulation leads to use after free. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The patch is identified as fe10872e53efba9cc36c66ac4ab3b41a839d5172. It is recommended to apply a patch to fix this issue.