|Summary:||media-libs/libpng: more buffer overflows|
|Product:||Gentoo Security||Reporter:||Thierry Carrez (RETIRED) <koon>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Thierry Carrez (RETIRED) 2004-08-04 10:47:18 UTC
Leaked from the latest Mozilla update : CAN-2004-0597 : - Remotely exploitable stack-based buffer overrun in png_handle_tRNS (pngrutil.c) - Dangerous code in png_handle_sBIT (pngrutil.c) (Similar code in png_handle_hIST). CAN-2004-0598 : - Possible NULL-pointer crash in png_handle_iCCP (pngrutil.c) (this flaw is duplicated in multiple other locations). CAN-2004-0599 : - Theoretical integer overflow in allocation in png_handle_sPLT (pngrutil.c) - Integer overflow in png_read_png (pngread.c) - Integer overflows during progressive reading. - Other flaws. [integer overflows] libpng-1.2.6 (planned for August 11) should be released to take care of these.
Comment 1 Thierry Carrez (RETIRED) 2004-08-04 11:13:04 UTC
Waiting for official libpng fix (v1.2.6)
Comment 2 Thierry Carrez (RETIRED) 2004-08-05 01:42:50 UTC
No official version yet at : http://www.libpng.org/pub/png/libpng.html We should apply the official security patches from : http://sourceforge.net/project/showfiles.php?group_id=5624&package_id=5683&release_id=257244 Mike : you did the last security works on libpng, may I ask you again for help on this one ? Could you bump libpng to 1.2.5-r8 with those patches ?
Comment 3 Sune Kloppenborg Jeppesen (RETIRED) 2004-08-05 02:47:31 UTC
GLSA drafted : security please review.
Comment 4 Thierry Carrez (RETIRED) 2004-08-05 03:05:22 UTC
1.2.5-r8 added to portage Arches : please test and mark stable for your arch. We need this rather quickly since other distributions advisories are already out. Thank you in advance !
Comment 5 Ciaran McCreesh 2004-08-05 03:25:17 UTC
Sparcy goodness added. Your home is at risk if you do not keep up repayments on a mortgage or other loan secured up on it.
Comment 6 Luca Barbato 2004-08-05 03:32:48 UTC
Comment 7 SpanKY 2004-08-05 04:32:56 UTC
Comment 8 Thierry Carrez (RETIRED) 2004-08-05 04:36:41 UTC
Thanks everyone, that was fast ! All supported arches are set, GLSA is ready to go.
Comment 9 Sune Kloppenborg Jeppesen (RETIRED) 2004-08-05 05:03:40 UTC
Comment 10 Bryan Østergaard (RETIRED) 2004-08-06 03:48:54 UTC
Stable on alpha.
Comment 11 foser (RETIRED) 2004-08-06 04:04:49 UTC
this got fixed halfway, according to the webpage 1.0.x is also vulnerable and it didn't get patched. I don't understand why this was missed ? I'm not even sure if 1.0 still is in use in the tree, but if it isn't it should be removed. If it is, it needs to be patched.
Comment 12 Thierry Carrez (RETIRED) 2004-08-06 04:33:27 UTC
GLSA 200407-06 already deprecated libpng-1.0.*. Version 1.0.15-r2 should have been removed by then. The problem is this package belongs to no herd, so security finds someone kind enough to do bumping, but that still doesn't take over package maintenance. When all keywords will be met, someone will have to remove all affected versions (<1.2.5-r8). Since most people from the security team don't have portage commit rights, someone else will have to do it. From a security standpoint, the problem is FIXED. People upgrading (either regularly or reading GLSA) are protected. People not upgrading are not protected, and they won't be more protected because we remove the ebuild. So the bug here is that libpng has no maintainer, so old or affected ebuilds aren't cleaned up. The problem is not that the GLSA treatment is incomplete. Setting this back to FIXED, feel free to disagree and comment.
Comment 13 foser (RETIRED) 2004-08-06 04:45:59 UTC
It is in a different SLOT, so in effect there is a chance (although slim) that ppl will have software with an insecure libpng. Those users need to be made aware that they should rebuild that software with a newer version (preferably 1.2.x) & remove 1.0 altogether to be completely safe. It doesn't really matter that there has been a GLSA that deprecated 1.0 : as long as 1.0 is in the tree, it is a security risk. I'm all for removing 1.0, the fact that it didn't happen in the past was that some packages specifically needed 1.0 . This doesn't seem to be the case anymore.
Comment 14 Thierry Carrez (RETIRED) 2004-08-06 05:09:13 UTC
I agree with you. It was already decided for the last GLSA that the 1.0 SLOT was not useful and I checked, back then, that it wasn't used anymore in any ebuild. I suppose it's still true. foser (or anyone with commit powers): could you remove the 1.0.* version left in the tree ? I can't :)
Comment 15 foser (RETIRED) 2004-08-06 05:21:20 UTC
done. maybe there should be a re-issue of the 1.0 deprecation GLSA to make sure ppl know about it (?) or some other form of letting ppl know.
Comment 16 Colin Leroy 2004-08-07 10:12:27 UTC
Don't mozilla, firefox & co need a new ebuild for this too?
Comment 17 Thierry Carrez (RETIRED) 2004-08-08 02:44:49 UTC
Yes. They already have some in testing. See bug 59419 for progress on this.
Comment 18 Joshua Kinard 2004-08-14 16:41:17 UTC