libpng 1.0.6 through 1.2.26, unknown chunks with zero data length

[Marcin Banasiak]

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

From the official advisory:

"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 (this is usually
    the case), 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."

[Elan Ruusamäe (glen666)]

libpng-1.2.26 prepared, however our builder infrastructure is down to build it

[Marcin Banasiak (megabajt)]

libpng-1.2.26 doesn't solve this vulnerability. The first fixed version will be 1.2.27 (or already released 1.2.27beta01).

[Marcin Banasiak (megabajt)]

I have commited patch that fixes this CVE.