Hi Mark and Fedora security folks,
Relatively recently, RHEL and Fedora put out updates for giflib problems with CVEs from 2005 ... I am curious how it took so long (nearly 4 years) to handle them ... and then took another month to get them into Fedora 9 (there is no update for F10, not vulnerable?) ... was it just an oversight? or were there other reasons?
http://lwn.net/Articles/333760/ has links to the updates and such (and a comment from a reader wondering just what I am asking) ...
thanks!
jake
http://lwn.net/Articles/333760/ has links to the updates and such (and a comment from a reader wondering just what I am asking) ...
Hello Jake; Tomas Hoger has just posted the details of this issue in the bug, see https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2005-3350#c7
Thanks, Mark -- Mark J Cox / Director, Red Hat Security Response
On Mon, 25 May 2009 20:21:12 +0100 (BST) Mark J Cox wrote:
Hello Jake; Tomas Hoger has just posted the details of this issue in the bug, see https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2005-3350#c7
Thanks, Mark.
I don't know much about CVE assignment and the like (but perhaps I should), but it would seem to me that the two CVEs from 2005 apply to libungif rather than giflib and that new CVEs should be created or applied for as it is a different package affected (though I assume they share much of the same code) ... it would also seem plausible that other distributions using giflib fell into the same hole ... or is this purely a Fedora/RHEL issue because they stuck with giflib 4.1.3?
jake
Hi Jake!
On Mon, 25 May 2009 13:43:08 -0600 Jake Edge jake@lwn.net wrote:
I don't know much about CVE assignment and the like (but perhaps I should), but it would seem to me that the two CVEs from 2005 apply to libungif rather than giflib and that new CVEs should be created or applied for as it is a different package affected (though I assume they share much of the same code) ...
If the affected code is re-used in multiple projects, the same CVE id is used to refer to the flaw in all projects that contain shared code (for examples, think of flaws in xpdf source code that usually need to be fixed in xpdf, poppler, cups, for older distros also kdegraphics, gpdf, ...; or mozilla flaws fixed in firefox, seamonkey, thunderbird).
While it's not quite obvious, libungif and giflib do not really seem to be different projects. I have not tried to track down all its history, but diffing their sources, the only real difference in 4.1.3 was that giflib supported LZW encoding and libungif did not. Excluding Makefile / configure / README differences, this boils down to about 200 lines of unified diff.
it would also seem plausible that other distributions using giflib fell into the same hole ... or is this purely a Fedora/RHEL issue because they stuck with giflib 4.1.3?
Following upstream releases more closely, this could have been fixed quite some time ago.
security@lists.fedoraproject.org