Bugzilla Bug 59424

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.