Libpng-1.2.26 security advisory -- April 12, 2008; revised April 14, 2008

This bug has been identified as CVE-2008-1382.

Tavis Ormandy advised us of a bug in libpng in its handling of
unknown chunks with zero data length.

We have examined the report and find that the bug exists in all
libpng versions since 1.0.6.  It only manifests itself when all
three of the following conditions exist:

   1. The application is loaded with libpng-1.0.6 through 1.0.32,
      libpng-1.2.0 through 1.2.26, or libpng-1.4.0beta01 through
      libpng-1.4.0beta19, and

   2. libpng was built with PNG_READ_UNKNOWN_CHUNKS_SUPPORTED
      or with PNG_READ_USER_CHUNKS_SUPPORTED (both are active
      in default libpng installations), and

   3. the application includes either a call to

          png_set_read_user_chunk_fn(png_ptr, user_ptr, callback_fn)

      or a call to

          png_set_keep_unknown_chunks(png_ptr, keep, list, N)

             with keep = PNG_HANDLE_CHUNK_IF_SAFE (2)
             or   keep = PNG_HANDLE_CHUNK_ALWAYS  (3)

We believe this is a rare circumstance.  It occurs in "pngtest"
that is a part of the libpng distribution, in pngcrush, and in
recent versions of ImageMagick (6.2.5 through 6.4.0-4).  We are
not aware of any other vulnerable applications.

When an application with the bug is run, libpng will generate spurious
warning messages about a CRC error in the zero-length chunk and an
out-of-memory condition, unless warnings are being suppressed.  There
is not actually a memory overflow, but the NULL pointer returned from
the memory allocator when it tries to generate a zero-length buffer
for the chunk data triggers the warning.  Later, there may be an error
when the application tries to free the non-existent buffer.  This has
been observed to cause a segmentation violation in pngtest.

Libpng-1.2.27 and later, and 1.0.33 and later, will not be vulnerable.
These are in beta and will be released on or about April 30, 2008.
Libpng-1.2.27beta01, which was released on April 12, is also not
vulnerable.