Re: The security of deflate-compressed streams with uncompressed-length field

On 5 February 2017 at 14:31, John Bowler
<[email protected]> wrote:
> Eh?  PNG chunk header:
> [length]
> [chunk-type]

Incorrect comparison. In your example, length is mandatory, as you
cannot know the chunk size without this field. There is no redundancy.
All application implementors understand it and know how to process it.
There is nothing to misunderstand or bad assumptions to be made.

In the topic under discussion, length is not mandatory, but an
optional, and more importantly, redundant piece of information.
Application implementors must check both the stated and the implied
uncompressed-length value and ensure that they agree. They may or may
not understand the security implications -- may or may not be aware
that bad things may happen if they don't make these checks. Hence the
very topic of this discussion.

> I think you do not understand the meaning of the word "streaming" as
> used traditionally in PNG discussions.  Streaming means *NOT*
> buffering.  Buffering the whole chunk is not streaming, regardless of
> how you obscure the buffering.

I don't think you understand the meaning of "I don't think you understand".

Implementors have been able to understand and implement zTXt and iCCP;
or if not, that meaning and that understanding would have (should
have) been required.

Whatever concept and methodology has been used for zTXt and iCCP, the
exact same can and should be used for future deflate-encoded metadata.
Using (easy-to-use) dynamic arrays, or using (easy-to-use) direct
reading from the *streamable* zlib *buffers*, or using anything else.

IIABDFI.

Sincerely,
Cosmin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot