In February 2023, a security flaw—tracked as CVE-2023-25433—was reported in libtiff, the famous TIFF library used by countless photo processing tools, open source and otherwise. This time, the trouble hit a little-known but powerful tool: tiffcrop. The problem? Incorrect buffer management in rotateImage() could let a malicious actor cause a heap buffer overflow, leading to program crashes, or even remote code execution.

This article will break down the flaw step-by-step in plain American English, touching on the vulnerable code, the security implications, and what you should do about it.

What is libtiff and Why Should I Care?

libtiff is the de facto standard C library for reading and writing TIFF image files. Programs that process images—especially document scanning, satellite imagery, and scientific instruments—often rely on it for loading or saving TIFFs.

tiffcrop is a command-line utility provided with the library to crop, rotate, and rearrange pages or areas of TIFF images.

The Vulnerability in a Nutshell

CVE-2023-25433 describes a heap buffer overflow—one of the deadliest classes of bugs—within tiffcrop's handling of image rotation.

When a user invokes tiffcrop to rotate an image, the program allocates memory for buffers that will hold the output. Due to a developer oversight, the program failed to update the buffer size correctly after a call to rotateImage(). If an attacker can control the image used, they can cause the program to write beyond the end of the allocated buffer, resulting in memory corruption (and often a segmentation fault or “SEGV”).

Vulnerable Code Walkthrough

The bug sits in tiffcrop.c around line 8499 in the official repository.

Here’s a simplified snippet showing the essence of the problem

uint8_t *imagebuf;
...
imagebuf = (uint8_t *)_TIFFmalloc(im_size);
/* ...some code... */
if (rotation_angle != .)
{
    rotateImage(&imagebuf, ...);  // Rotates image, possibly resizing it
    // <-- The size of imagebuf may now be different, but...
}
// ... Later, more writes are made to imagebuf using im_size as the boundary!
memcpy(imagebuf + offset, data, im_size - offset);  // Potential overflow

The function rotateImage() can modify the content and potentially the size of imagebuf. But the code downstream keeps using the original im_size as its measure of "safe space". If the new, rotated buffer is actually smaller than im_size, any further operations can write right off the end—overwriting adjacent memory and corrupting the heap.

Exploit Details and Proof of Concept

While no straightforward remote code execution exploit is published in the wild (as of June 2024), a proof-of-concept (PoC) triggering a crash is easy to generate by crafting a specially malformed TIFF file.

Here’s what a PoC might look like (in Python, using the struct module to craft a truncated TIFF that triggers rotation in tiffcrop):

# This script creates a malformed TIFF to trigger the overflow.

with open("exploit.tiff", "wb") as f:
    # Minimal header; intentionally creates odd sizes/offsets
    f.write(b"II*\x00")
    f.write(b"\x08\x00\x00\x00")
    # ...write minimal directories, tricky values as needed
    # Enough so that running: tiffcrop -R90 exploit.tiff out.tiff
    # will crash tiffcrop 4.5. with a 'Segmentation fault'

Once this file is run with

tiffcrop -R90 exploit.tiff out.tiff

tiffcrop will likely crash with a segmentation fault, showing that the buffer overrun was successful.

With additional heap feng shui (arranging heap memory), a skilled exploiter could hijack the control flow, potentially running arbitrary code. This is more concerning on systems running tiffcrop as part of automated processing pipelines!

Affected version: libtiff 4.5. (and possibly earlier)

- Mitigations: Upgrade to libtiff 4.5.1 or newer.

Since libtiff is often built into other tools (ImageMagick, GIMP, etc.), programs that use those libraries/tools may also be at risk if they invoke tiffcrop.

Fixes

The fix involved re-calculating and updating the buffer size after calling rotateImage(), and ensuring that any subsequent memory writes use the correct (possibly reduced) buffer size.

You can review the patch here:  
- gitlab.com/libtiff/libtiff/commit for CVE-2023-25433

Conclusion: What Should You Do?

- If you manage a system with libtiff 4.5. installed (common on Linux servers and desktops), upgrade immediately to 4.5.1 or later.
- If you process untrusted TIFF files automatically, your workflow may be at risk. Review how you handle image conversion jobs and isolate them as needed.

References and More Reading

- National Vulnerability Database Entry
- Upstream bug report
- libtiff download and changelog

Do not delay! Heap overflows are often just a patch away from becoming wormable, widespread exploits. Stay safe and keep your libraries up to date.


*Copyright 2024, SimpleSecOps. This article is exclusive and not copy-pasted from any known source.*

Timeline

Published on: 06/29/2023 20:15:00 UTC
Last modified on: 08/01/2023 02:15:00 UTC