[Png-mng-security] vulnerability in png_decompress_chunk()

[John Bowler]

From: Glenn Randers-Pehrson [mailto:glennrp at gmail.com] 
>So the choices are either to ignore the problem in 1.2 or
>make an internal change in 1.2.43 that imposes appropriate limits.

Right.

>I think we have always been reluctant to impose arbitrary (even if
>appropriate) limits.  If we do, I think we must allow users to
>override them.

That's not really an option because:

>It has been said that even just *adding* a new exported function
>breaks ABI compatibility, but I'm not sure that I really believe that.

Adding a new API that *must* be called in order for existing functionality to continue to function breaks the ABI - it's a semantic break rather than a syntactic one, but that's just as bad.

In this case if the call must be made to set the limit (as in 1.4) then either this is an ABI change or the change doesn't fix the vulnerability.  In effect 1.2.43 would be ABI compatible only so long as the (general) vulnerability was not fixed.  That makes it pointless to change 1.2 in this way.

>I think maybe the best approach is to leave 1.2.42 alone and just tell
>people it's time to upgrade if they want to avoid this newly publicized
>vulnerabilty.

A perhaps more correct statement is to say that applications concerned with the general vulnerability (DoS based on memory consumption) have to call new APIs and these APIs are only available in 1.4

This does mean that you will be changing the png_struct or png_info structure in 1.4 (as in the current 1.4.1beta06 - adding a member to a structure visible in the ABI; at extra 4 bytes at the end of png_struct).  IRC that happened several times in 1.2.

John Bowler <jbowler at acm.org>