[<prev] [next>] [day] [month] [year] [list]
Message-ID: <537a4ffc-7e54-470f-8c64-3dcf5131a606@hoffie.info>
Date: Fri, 26 Sep 2025 09:30:24 +0200
From: Christian Hoffmann <christian@...fie.info>
To: oss-security@...ts.openwall.com
Subject: libtiff 4.7.0: Out-of-Bounds Write in TIFFReadRGBAImageOriented()
(CVE-2025-9900)
Hi,
on 2025-09-23 CVE-2025-9900 was published for libtiff 4.7.0 and it seems
to have gained some traction due to the potential risk of code execution
via malicious TIFF files.
I was wondering about the real world criticality for software which uses
libtiff. I did some investigation and I'm looking for validation or
falsification of those findings.
# Background
According to the CVE details, the CVE is about an advisory [1] by Github
user SexyShoelessGodofWar. Further research turns up Issue #704 in the
Gitlab libtiff issue tracker [2] from 2025-05-14 which also contains a
reproducer (attached testGen.py and poc_crasher.c) and links the
relevant patch [3].
# Observations
1. poc_crasher.c calls libtiff's TIFFReadRGBAImage with width and height
values which are smaller then the actual TIFF dimensions when an image
with width or height > 10000 is supplied. Based on the libtiff API
documentation, this is a supported use case ("If the raster dimensions
are smaller than the image, the image data is cropped to the raster
bounds." [4]).
2. The test file (generated via testGen.py) does not show any obviously
suspicious behavior when loaded in GIMP, imagemagick or evince. I have
not checked all possible call sites, but I believe that at least those
listed tools always call the affected function TIFFReadRGBAImage with
the actual TIFF's dimensions and as such don't hit the bug.
SexyShoelessGodofWar also confirmed that Evince did not seem affected
and that other tools are still under investigation.
3. When loading a plain 1024x768 sized TIFF file (generated via GIMP),
libtiff exhibits the same value when passed height=256. This suggests
that the actual libtiff usage is very relevant and the potentially
malicious TIFF file maybe less so.
# Fixes
Besides Merge Request 732 [3], Merge Request 738 [6] also touches this
code path and may be relevant.
libtiff 4.7.1 was released on 2025-09-18 and lists Issue #704 (this CVE)
as fixed [7].
# First conclusion
Based on my understanding, libtiff users would only be affected by this
issue under specific circumstances. The issue would be limited to
libtiff users which call TIFFReadRGBAImage or TIFFReadRGBAImageOriented
with a smaller height than the actual TIFF's height (i.e. cropping the
image on read). For example, this would be exploitable if an application
used a static or attacker-supplied height which is smaller than the
height of the attacker-supplied TIFF.
My gut feeling is that this should not be common (especially since this
would crash during ordinary usage), but it's hard for me to tell if this
matches reality.
I currently do not see a way for an attacker to confuse libtiff into
returning a small height to the libtiff user and later use a larger
height from the same TIFF file internally.
Note:
- I do not want to downplay the issue. There seems to be an actual bug
and it may be security-relevant in more cases than I can think of. I'm
posting this to start a potential discussion about that.
- I'm not affiliated with the researcher, I'm just sharing my findings
and observations in the hope that they help libtiff downstream users and
in the hope that further confirmation or falisification of those
findings appear.
Kind regards,
Christian
[1]
https://github.com/SexyShoelessGodofWar/LibTiff-4.7.0-Write-What-Where?tab=readme-ov-file
[2] https://gitlab.com/libtiff/libtiff/-/issues/704
(libtiff-gitlab-issue-704.txt)
[3] https://gitlab.com/libtiff/libtiff/-/merge_requests/732
[4]
https://gitlab.com/libtiff/libtiff/-/blob/5fe20d0e9aba49a6a350ed533459d1505203838f/doc/functions/TIFFReadRGBAImage.rst
[5]
https://github.com/SexyShoelessGodofWar/LibTiff-4.7.0-Write-What-Where/issues/1#issuecomment-3335973158
> I had caused crashes in one application (but interestingly I recall,
> it was through memory exhaustion), but further investigation was
> earmarked for future work - I've not really looked more deeply into
> this. Some of the other applications i'd tried. Evince was one of
> them, and that didn't crash - this is generally just due to some pre-
> processing of the file or additional checks that sit infront of the
> vulnerable code path. I speculate a little here, but am pretty certain
> this will be the mitigating factor.
[6] https://gitlab.com/libtiff/libtiff/-/merge_requests/738
[7] https://libtiff.gitlab.io/libtiff/releases/v4.7.1.html
> tif_getimage.c: Fix buffer underflow crash for less raster rows
> at TIFFReadRGBAImageOriented() (fixes issue #704)
Vendor CVE pages:
https://access.redhat.com/security/cve/cve-2025-9900
https://www.suse.com/security/cve/CVE-2025-9900.html
https://ubuntu.com/security/CVE-2025-9900
https://security-tracker.debian.org/tracker/CVE-2025-9900
View attachment "poc_crasher.c" of type "text/x-csrc" (2823 bytes)
View attachment "testGen.py" of type "text/x-python" (1157 bytes)
View attachment "libtiff-gitlab-issue-704.txt" of type "text/plain" (2548 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
