PyPI · Pillow
Pillow: Memory disclosure and segfault in libtiff encoder via crafted TIFF tags
============================================================================
Memory disclosure and segfault in libtiff encoder via crafted TIFF tags
Location: src/encode.c:1014 in PyImaging_LibTiffEncoderNew()
Commit: a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
A crafted TIFF file of a few hundred bytes makes Pillow copy an attacker-chosen amount of its own process memory into the TIFF it writes back out, or crash the process outright. The trigger is an ordinary Image.open() followed by a bare im.save(fp, "TIFF"). The only precondition is that the application re-saves images as TIFF. When the uploaded file is compressed, Pillow routes that save through libtiff automatically, with no options from the application. The attached reproducer does this with a 356-byte LZW TIFF: one crafted tag comes back holding 65536 bytes taken from _imaging.so's read-only data, and a second crafted tag makes the worker die with SIGSEGV on every run.
The bug is in PyImaging_LibTiffEncoderNew (src/encode.c). It decides what arguments to pass to the variadic TIFFSetField() from the shape of the Python value (scalar, tuple or bytes). It assumes its ImagingLibTiffMergeFieldInfo() call defined how libtiff will read them. But TIFFMergeFieldInfo() never overrides libtiff's built-in field table, so libtiff reads the arguments according to its own definition of the tag:
Where that unwritten slot points depends on the compiler. In the tested clang build it points into _imaging.so, and a larger count returned thousands of pointers into libpython, libc and libtiff, which defeats address-space randomisation for anyone chaining another bug. When the application preserves metadata with tiffinfo=im.tag_v2, a 64-bit entry turns ActiveArea into a 16-byte read from an address the attacker chooses. All observed memory errors are reads; no out-of-bounds write was found.
Other branches of the same loop share the defect and are reachable from crafted TIFFs or from EXIF in JPEG/PNG/WebP re-saved as compressed TIFF. These are the bytes, RATIONAL-tuple and typed-tuple branches, and a BYTE-typed ColorMap. The file-reachable forwarding was introduced in a3d45e9cefd0 ("Added custom int and float TIFF tags") and first released in 5.4.0.
PyImaging_LibTiffEncoderNew (src/encode.c:777-1060) chooses the argument
list it hands to the variadic TIFFSetField() from the Python value of each
tag — scalar vs. tuple vs. bytes, and a type that is either autodetected or
copied from the source file's IFD — and assumes that its own
ImagingLibTiffMergeFieldInfo() registration defines how libtiff will read the
va_list. It does not: libtiff keeps its built-in definition for every tag it
already knows, and core tags are never registered at all. libtiff therefore
consumes the varargs as (count, pointer), (pointer) or three pointers
according to its field table, whatever Pillow actually pushed. The encoder
never consults that table (TIFFFindField / TIFFFieldPassCount /
TIFFFieldWriteCount / TIFFFieldDataType) before the call.
The most severe instance, and the one the attached reproducer exercises: when a
TIFF is re-saved through the libtiff writer, every tag of the source IFD that
Pillow does not recognise is forwarded to libtiff with TIFFSetField(). A
count-1 integer entry is passed as a single scalar vararg. If libtiff's own
field table defines that tag number as an array field, libtiff consumes the
varargs as (count, pointer) or (pointer) instead, so the attacker's integer
becomes either the number of bytes to copy from a never-written vararg slot, or
the source address itself. The same mismatch is reachable through the typed
tuple branches (tuple length consumed as a pointer for fixed-count built-in
tags such as CFARepeatPatternDim, even when the source file is well-formed),
the bytes, TIFF_RATIONAL-tuple and core-tag branches of the same loop;
those are listed
under Other branches with the same defect below and need to be covered by the
same fix.
A 181-byte TIFF (16×16 RGB, one LZW strip, plus one extra IFD entry
50740 / LONG / count 1 / value 4096 — DNGPrivateData) opened with
Image.open() and saved with a bare im.save(buf, "TIFF") produces a 4296-byte
output whose tag 50740 holds 4096 bytes that occur nowhere in the input; scanning
/proc/self/mem finds them in the read-only data segment of _imaging.so.
Changing the extra entry to 50829 / LONG / 1 / 64 (ActiveArea) makes the same
two calls segfault in memcpy(dst, src=0x40, n=16) under
ImagingLibTiffSetField ← PyImaging_LibTiffEncoderNew. An ASan build of the
extensions reports READ of size 4096 in memcpy called from
src/encode.c:1014 for the first input.
_save copies all tags of the opened image into the libtiff attribute list.
For a tag that is neither in LIBTIFF_CORE nor in TiffTags.TAGS_V2, no type
is recorded, so the value goes through untyped:
# src/PIL/TiffImagePlugin.py:1782
supplied_tags = {**legacy_ifd, **getattr(im, "tag_v2", {})}
…
# :1959-1982
for tag, value in itertools.chain(ifd.items(), supplied_tags.items()):
if tag not in TiffTags.LIBTIFF_CORE:
…
elif isinstance(value, (int, float, str, bytes)) or …:
type = TiffTags.lookup(tag).type # None for 50740, 50829, …
if type:
types[tag] = type
if tag not in atts and tag not in blocklist:
…
atts[tag] = value # plain int 4096
compression defaults to the source image's im.info["compression"]
(TiffImagePlugin.py:1731-1746), so a compressed source selects the libtiff
writer without the application asking for it.
In the encoder the untyped int is autodetected as TIFF_LONG
(src/encode.c:805-815), the tag is "registered" as a scalar custom field, and
then set with one 32-bit vararg:
// src/encode.c:844 (is_var_length = 0 → writecount 1, passcount 0)
if (ImagingLibTiffMergeFieldInfo(&encoder->state, type, key_int, is_var_length)) {
… continue;
}
…
// src/encode.c:1013-1016
} else if (type == TIFF_LONG || type == TIFF_IFD) {
status = ImagingLibTiffSetField(
&encoder->state, (ttag_t)key_int, (UINT32)PyLong_AsLong(value)
);
The registration does not do what the caller assumes. TIFFMergeFieldInfo()
only adds definitions for tags libtiff does not already know and returns 0
(success) either way, so for tags in libtiff's built-in table the built-in
definition stays in force. Queried against the linked libtiff 4.5.0 after
exactly Pillow's merge call:
50740 DNGPrivateData type=BYTE passcount=1 writecount=-1 (unchanged)
50829 ActiveArea type=LONG passcount=0 writecount=4 (unchanged)
65000 CustomField type=LONG passcount=0 writecount=1 (Pillow's definition, tag was unknown)
libtiff's setter for FIELD_CUSTOM tags then interprets the va_list
according to its definition: for passcount=1 it reads va_arg(ap, int) as
the element count — the attacker's 4096 — allocates count * size bytes and
memcpys that many bytes from va_arg(ap, void *), a slot
PyImaging_LibTiffEncoderNew never wrote. On x86-64 that slot is register
rcx; in this build it holds a pointer into _imaging.so's .rodata, so the
copy succeeds deterministically (a value of 2 000 000 also succeeds and yields a
2 000 200-byte output). TIFFWriteDirectory writes the copied bytes into the
output file as the tag's value. For fixed-count array fields (passcount=0,
`writecount=
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.