Memory corruption (overflow) in tiffcp

Memory corruption (overflow) in tiffcp, version: 4.5.1

Function: readSeparateTilesIntoBuffer

Line 1740: imagew is multiplication of image width, bit per sample and sample per pixel. All those fields are in tiff header and read from the file by libtiff. An attacker could create a tiff image with fields values so the multiplication result will be larger than MAX_INT.

Line 1757: iskew type is int32. In case imagew is large (>max_int), and the results of tilew*spp not large enough, iskew will be negative.

Line 1575: in case inskew/outskew (depending on the if statement) is negative, in the second loop, a write out of bound occurs and the tool will yield a segmentation fault.

--

This can be exploited in different ways, using the handling of -m option:

In cpImage function, which call to readSeparateTilesIntoBuffer function, there is call to limitMalloc (line 1591), which allocate memory to the output image. In this function, there is a check to ensure that the requested allocation size is not larger than 256MB.

To demonstrate the vuln, we want scanlinesize to be larger than MAX_INT, the maxMalloc should be larger, and this can be done by passing -m parameter. Another option, is to cause this limitation to be ignored by passing 0 to -m option. In addition, there is no check of the passing parameter. In case the user pass number larger than 2^44, there will be overflow.

POC: POC.tif

tiffcp POC.tif -p contig -m 4294967296 out.tiff

tiffcp POC.tif -p contig -m 4098 density_out.tiff

tiffcp POC.tif -p contig -m 0 out.tiff

--

CVE-2023-40745 (CVE-2023-38288)

Reported by INTEL ASSERT (Cohen, Yaakov; Butterman, Yocheved;Frolov, Polina; Haenel, Arie)

--