Weekly Edition
Return to the Security page
| |||||||||||||
Image handling vulnerabilitiesBugs 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 security issues. 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. (Log in to post comments)
Image handling vulnerabilities Posted Apr 24, 2008 22:50 UTC (Thu) by dvdeug (subscriber, #10998) [Link] It goes beyond images; it seems we get a vulnerability about video or sound on a weekly basis, too. It seems that few programs thoroughly verify their input, even when it likely comes from untrusted sources on the net.
Image handling vulnerabilities Posted Apr 25, 2008 0:54 UTC (Fri) by bronson (subscriber, #4806) [Link] Notice how there's never vulns with decoding PCM sound files. Why? Because PCM is easy. The more complex a file format, the harder it is to get right. Packetized streams like MPEG and AVI are outrageously complex to decode and process. It requires huge amounts of code with non-trivial stateful interaction between components. I'm not sure it's even possible to thoroughly verify a zip archive, much less an MPEG stream!
|
|||||||||||||