On Mon, 14 Jul 2025 at 12:15:36 +0100, Simon McVittie wrote:
I happened to notice that a buffer overflow was reported and fixed
upstream, involving parsing a JPEG file with multiple chunks of embedded
ICC colour-correction data.
Cyril reminded me that the fixed version is still only in unstable, and
has not migrated to trixie. I've been reluctant to ask for an unblock or backport the change into bookworm, because I was concerned about
possible regressions.
For context, gdk-pixbuf has three main use-cases:
- GTK apps use it to load trusted resources like icons. Security doesn't
really matter here: an attacker should not have the opportunity to
inject a crafted, malicious icon into the app.
- Some older image viewers such as gthumb, eog and eom use it as a
general-purpose image loader. IMO this is the most concerning exposure
to untrusted images. It is increasingly clear that early 00s C code
written in the typical ad-hoc style is not a great fit for this use,
and upstream no longer recommend gdk-pixbuf for this purpose: instead
they recommend using something sandboxed and/or written in a memory-safe
language, like glycin (which uses sandboxed Rust code). The version of
GNOME in trixie defaults to installing loupe (a glycin-based image
viewer) in preference to eog (an older gdk-pixbuf-based viewer)
but other desktops like MATE and bookworm's GNOME still install
gdk-pixbuf-based image viewers, and existing GNOME installations
upgraded to trixie will still have eog.
- libgnome-desktop uses gdk-pixbuf for thumbnailing. This is exposed to
untrusted images, and in principle more dangerous than the image viewer
use-case because thumbnailing is usually automatic; but since 2017 it's
rather strictly sandboxed with bubblewrap, mitigating vulnerabilities.
The buffer overflow CVE-2025-7345 was discovered via fuzzing and we do
not know what its impact is: could be essentially harmless in practice,
could be denial of service, could conceivably be arbitrary code
execution when not sandboxed, I have no idea.
gdk-pixbuf's image loading code is likely to become a wrapper around
glycin (at least on release architectures) during the GNOME 49 cycle,
avoiding this whole class of potential vulnerabilities, but that work is currently ongoing upstream and was not ready in time for trixie, so we
can't wait for it.
(It has not been fixed in a release, only in
the upstream development branch.)
This is still the case, so presumably upstream is not treating this as a high-priority fix at the moment.
Looking at our friends, colleagues and/or competitors in other distros,
Fedora has left the CVE unfixed for the moment, but Ubuntu has applied a
patch in their stable/LTS releases (and might be able to share whether
they have experienced regressions).
Since uploading the fixed version to unstable, we've had a report of a >regression, https://bugs.debian.org/1109199, which I forwarded upstream
as https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/262. I cannot
reproduce the regression, and the regression reporter has not provided
enough details to make it actionable
The regression reporter now says they cannot reproduce the regression
either. I don't know what was happening there.
I think we should probably leave this unfixed in stable and LTS for now, >until we have a better idea of whether the regression is a real thing.
What does the security team want to do about this? Fix in trixie now, or
fix via trixie-security before or after 13.0, or wait for 13.1?
I am by no means an expert on either the gdk-pixbuf codebase, the finer >points of JPEG parsing, or reproducing fuzzer-generated crashes in a
more reasonable environment, so I would very much appreciate it if
someone who is better at those topics (and ideally someone who can spend >their paid time on it!) can take it from here.
This is still the case and I would appreciate help.
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)