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

[glennrp at comcast.net]

----- Original Message -----
From: "John Bowler" <jbowler at frontiernet.net>

> 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.

    Still waiting for a definitive answer to whether it's OK to
    do this any more without a minor version bump (i.e., 1.4.0 to
    1.5.0 and libpng14.so to libpng15.so).

    For 1.4.1beta07 I am planning to implement essentially what's in
    beta06, but with the opportunity for the downstream libpng
    builder to impose default limits on the maximum size and
    number of compressed chunks via #define and for the application
    writer to override the limits via "png_set_*()" functions.  The
    defaults set in our distribution will be 0 meaning unlimited.
    That includes the get|set functions and a new png_struct member
    to hold the malloc limit (1.4.0 already has one for the chunk
    counter).

    For 1.2.43 I am planning to implement the same but without
    the get|set functions and without a new member in png_struct.
    The memory limit will be a constant that can be defined by
    the downstream libpng builder, default 0, meaning unlimited.
    I don't see a way of imposing a limit on the number of
    compressed chunks because that requires a counter in the
    png_struct.

    Libpng-1.4.1 and 1.2.43 (and 1.0.53) will use the fast
    two-pass png_decompress_chunk() that measures the
    chunk before allocating memory for it.

    I have posted patches for Firefox/Mozilla to the
    bugzilla.mozilla.org bug #497056 along these lines,
    to replace the png_decompress_chunk() function with
    the two-pass function in the embedded library and a
    fixed 4-MB maximum on the size of decompressed iCCP
    chunks. If Firefox (or other gecko-based application)
    is built with the system libpng older than 1.4.1, then
    it uses a replacement malloc_fn() to impose the 4MB
    limit on the decompressed iCCP chunk size
    and increased the size of zbuf_size for iCCP chunk
    decompression to 32k, That's not an ideal solution
    but I don't have any other ideas.

    In libpng-1.4.0, 0x7fffffff means an unlimited
    number of chunks allowed, but "0" seems simpler
    to implement and to explain.  It doesn't really make
    any practical difference so I think it's OK to make
    this change in 1.4.1.

    Glenn