Common Vulnerabilities and Exposures assigned an identifier CVE-2006-4484 to the following vulnerability: Buffer overflow in the LWZReadByte_ function in ext/gd/libgd/gd_gif_in.c in the GD extension in PHP before 5.1.5 allows remote attackers to have an unknown impact via a GIF file with input_code_size greater than MAX_LWZ_BITS, which triggers an overflow when initializing the table array. References: http://bugs.php.net/bug.php?id=38112 http://cvs.php.net/viewvc.cgi/php-src/ext/gd/libgd/gd_gif_in.c?r1=1.10&r2=1.11 http://www.php.net/ChangeLog-5.php#5.1.5
This issue was addressed in php packages in following advisories: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2006-0669.html Red Hat Application Stack: http://rhn.redhat.com/errata/RHSA-2006-0688.html Fix is included in upstream gd version 2.0.34. Versions of gd currently shipped in Fedora are not affected. Related issue affecting other packages that use derivate of the same GIF handling code: CVE-2007-6697 (SDL_image), CVE-2008-0553 (tk), CVE-2008-0554 (netpbm)
graphviz includes and seems to use local copy of gd code. I haven't investigated whether graphiz has any way to load GIF images, so I can't tell if it's really affected by this problem. Patrick, Alex, any thoughts? Can graphiz packages be modified to use system gd library instead of local copy? If graphviz is affected, only F7 version (2.12) needs to be fixed, as it ships with embedded gd 2.0.33. F8 version (2.14.1) embeds fixed gd 2.0.34.
Actually, I'm pretty sure the version of graphviz-gd in F8 uses the system gd, or so the package's dependency on libgd.so.2 would suggest to me. So what I would immediately consider is pushing 2.14.1 to F7. Any objections to that? Cc'ing John Ellson (graphviz upstream) and Debarshi Ray (graphviz downstream, anjuta maintainer). Debarshi, anjuta will need a rebuild if I bump graphviz. Just a heads-up.
(In reply to comment #3) > Actually, I'm pretty sure the version of graphviz-gd in F8 uses the system gd, > or so the package's dependency on libgd.so.2 would suggest to me. Thanks for clarification. I haven't investigated F8 version closely once I've notices gd version there is fixed. I've seen gd being build on F7 (according to build.log from latest F7 package). > So what I would immediately consider is pushing 2.14.1 to F7. Any objections > to that? If rebase is not practical, patch linked in the initial comment (in PHP CVS repo) should trivial to adjust for graphviz.
Your risk is causing problems with anjuta and doxygen by going from 2.12 to 2.14 Graphviz is happy with a system gd >= 2.0.34, and fc7 has 2.0.35, so a more conservative change would be to just rebuild graphviz-2.12. Check that --with-mylibgd is *not* set in the spec file The upstream sources already contain this patch, for anyone using graphviz on systems with older versions of gd.
(In reply to comment #3) > Cc'ing John Ellson (graphviz upstream) and Debarshi Ray (graphviz downstream, > anjuta maintainer). Thank you for the heads up. > Debarshi, anjuta will need a rebuild if I bump graphviz. In fact the Anjuta package and a few of its dependencies -- libgdl (formerly anjuta-gdl), gnome-build and autogen -- in Fedora are seriously outdated. I inherited some of them sometime ago (yet to get autogen), and am gradually freshening them up. I am going to submit a fresh Anjuta package for F-7, F-8 and Rawhide sometime soon, so the re-builds will anyway happen one way or the other.
graphviz-2.12-10.fc7 has been submitted as an update for Fedora 7
graphviz-2.12-10.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Red Hat Application Stack: php: http://rhn.redhat.com/errata/RHSA-2006-0688.html Red Hat Enterprise Linux: php: http://rhn.redhat.com/errata/RHSA-2006-0669.html gd: http://rhn.redhat.com/errata/RHSA-2008-0146.html Fedora: graphviz: https://admin.fedoraproject.org/updates/F7/FEDORA-2008-1643
(In reply to comment #0) > http://cvs.php.net/viewvc.cgi/php-src/ext/gd/libgd/gd_gif_in.c?r1=1.10&r2=1.11 This is now: http://svn.php.net/viewvc?view=revision&revision=216488 http://svn.php.net/viewvc?view=revision&revision=216545