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

On Sun, Feb 5, 2017 at 11:29 AM, Cosmin Truta <[email protected]> wrote:
>  I disagree with [John] only
> on feasibility (specifically claiming that "it can be done correctly
> and it's not that much of a big deal"), but not on validity of the
> issues as a whole (specifically accepting that "it may be done
> incorrectly, and that may be a big deal").

Yes; that is the issue, as yet unresolved.

> We shouldn't stop using qsort() just because many people can't get
> quicksort right. It's been done right, it's in the standard C library,
> let's use it.

I'm not talking about implementing deflate (RFC 1951): I've always
assumed that *zlib* would be available.  I'm talking about
implementing a correct use of the zlib API in the presence of
arbitrary zlib (RFC 1950) streams, including malicious ones.

> About the PNG specification, I suggest (as I had also done,
> previously) adding non-normative sections with sample code.

Which was done for the gamma handling then, maybe, the righteous and
correct intentions dropped by the wayside.  I'm 100% in favor of this.
I doubt ISO will ever formally adopt an approach but this is
skunk-works; if you want to do it I will support it.

Collaborative code does work; my attempts have been not-very-good.
Glenn pointed out that my so-called example code had somehow blossomed
into a major piece of software engineering.  (He didn't say it that
way; it was pngcp, which I originally wrote as a simple example of a
specific use of libpng.)

>There won't be changes in zTXt or iCCP, and implementors (C
> language implementors, to be exact) need this awareness.

Well, iCCP has a length field, perhaps by accident but it turned out
to be very useful.   That's nit-picking; zTXt didn't and, IRC (it was
years ago) the proposer (Greg?) was proposing something to compress a
hypothetical long text chunk.  For example the typical US license
agreement (I can safely assert I have never read a single one to the
end.)

On such a chunk, such a set of text, assuming a buffer capability is
apparently reasonable.  So zTXt got adopted.

Willem's point stands; considerably rephrased, dudes don't decompress zTXt.

-- 
John Bowler <[email protected]>
+1 (541) 450-9885
PO BOX 3151
KERBY OR 97531-3151
USA

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