Threats tagged 'ghsa-xvh5-g6gv-559v'

``` ============================================================================ 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: - For a counted array tag such as DNGPrivateData (50740), a count-1 integer in the source file is taken as the byte count. The data pointer is then read from an argument slot Pillow never wrote, and that many bytes are copied into the output. - For a fixed-size array tag such as ActiveArea (50829), the integer itself is used as the source address. 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. ## Details `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 `ImagingLibT