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.
Waiting for official libpng fix (v1.2.6)
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 ?
GLSA drafted : security please review.
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 !
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.
marked ppc
added hppa/arm/amd64
Thanks everyone, that was fast ! All supported arches are set, GLSA is ready to go.
GLSA 200408-03
Stable on alpha.
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.
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.
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.
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 :)
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.
Don't mozilla, firefox & co need a new ebuild for this too?
Yes. They already have some in testing. See bug 59419 for progress on this.
mips stable.
