[Zlib-devel] known bugs in distance-checking code?

[Greg Roelofs]

Hi, Mark,

> That png does indeed have an invalid distance too far back.  The 
> relevant portions are shown below disassembled.  There are five 
> literals followed by a match with distance 132.  The maximum distance 
> allowed at that point is five.  With the old inflate, it will most 
> likely copy zeros from the sliding window, since it was allocated with 
> calloc(), if this is the first use of that window.  If the inflate 
> structure is being reused, e.g. with inflateReset(), then it would copy 
> something from near the end of the last image.

Ah, many thanks for the quick analysis!  Could you pop this one through
your tools, too?  It dies after 100 bytes:

	http://audio.rightmark.org/test/audiotrak-prodigy192-1644/thd.png

(6760 bytes).  In this case, we can tell what software generated it.

> So the png file was improperly generated somehow.  In my opinion, it is 
> better to catch these than to let some buggy deflator out there 
> continue in its life of crime.

I fully agree that we need to flag these, and in the case that they're
actually reading beyond the bounds of the allocated array (not the case
here?), we should barf rather than allow unpredictable results.

On the other hand, the reality is that users don't care; they just want
to see the images on the web sites, and the fact that IE and older
versions of Netscape/Mozilla/whatever all can do so while newer versions
can't is the mark of a bug in the newer versions, regardless of whether
the images really are invalid.

What we're likely to see is patches that hack the code to change the
error to a warning (and maybe that force the buffer to be initialized
or whatever).  Some guidance from you on the most proper compromise
might be a good idea. ;-)

I'll pass your analysis along to the PNG list--thanks again.

Greg