Bugs that linger for eight years without a fix are probably annoying to
whoever reported them; perhaps others as well. When those bugs have
possible security implications, it is hard to see how they can remain
unfixed for even eight months, let alone years, but that appears to be the case
with some GTK image handling bugs. Code to handle image formats has been
the source of numerous vulnerabilities along the way, which makes it even
harder to see why these have languished so long.
A call for ideas for a hackfest on the GNOME foundation mailing list seems
like a bit of a strange place to find information about vulnerabilities,
but in the ensuing thread, Michael Chudobiak brought up some bugs that he would like to see addressed,
perhaps as part of a hackfest:
I'd like to suggest one possible topic: The pixbuf loaders. They're slow
and memory intensive, and this drags down anything that needs thumbnails
(Nautilus, etc). There is a lot of opportunity to improve the
responsiveness of the desktop here.
The bugs he listed were from 2002 (80925), 2004 (142428), and
2008 (522803), but
Alan Cox mentioned that he reported one of them as a GNOME
security bug "about eight years ago". In his opinion all of the bugs were
of the "well known, never fixed" variety. Because the code in question
lives in GTK—used by many GNOME applications—"quite a few gnome
apps fed small compressed images explode".
The basic problem is that the routines handling images create the
full-resolution image in memory regardless of the size requested. In
addition, various memory-intensive techniques are used to scale the image
to the requested size. This impacts Nautilus and other GNOME programs
that create thumbnails of large images.
Presumably, a denial of service, at a minimum, can result from these
operations, though there may be other ways to exploit any program crashes
that result. Cox has a plan to see them get fixed:
Unfortunately they are well known but nobody seems to care. I'll forward
your message to the vendor security list and we'll see what happens.
Probably the bug just needs to be made *very* public to incentivise
people to fix it 8)
The vendor security list, often abbreviated vendor-sec, is a closed mailing
list for distribution security teams to exchange information about vulnerabilities in
various programs. It is closed so that bugs that are not publicly known
can be freely discussed. Whether Cox's posting to that list spurs any
action remains to be seen.
It is a rare week where LWN does not report some kind of image handling
botch as a new vulnerability. This week, a cups vulnerability in handling
PNG files could lead to a denial of service; last week we reported an Opera
vulnerability in handling images in HTML canvas elements that could
possibly lead to arbitrary code execution. Image handling
is an area where all bugs need to be scrutinized carefully for potential
Hopefully, part of the problem is that the GNOME hackers did not realize
the security implications of the bugs. There does seem to be ample
complaint about performance problems, though, to get some kind of action
over the last six or eight years. This is a set of related bugs that have
seemingly been overlooked for a long time. Perhaps that time is now coming
to an end.
to post comments)