The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
libpng Zero-Length Chunks Incorrect Handling
------------------------------------------------------------------------
SUMMARY
Applications using libpng that install unknown chunk handlers, or copy
unknown chunks, may be vulnerable to a security issue which may result in
incorrect output, information leaks, crashes, or arbitrary code execution.
The issue involves libpng incorrectly handling zero length chunks which
results in uninitialized memory affecting the control flow of the
application.
DETAILS
Vulnerable Systems:
* libpng-1.0.6 through 1.0.32
* libpng-1.2.0 through 1.2.26
* libpng-1.4.0beta01 through libpng-1.4.0beta19
All these versions in the case that they were built with
PNG_READ_UNKNOWN_CHUNKS_SUPPORTED or PNG_READ_USER_CHUNKS_SUPPORTED
(default configuration)
Immune Systems:
* libpng version 1.2.27
* libpng version 1.0.33
* libpng version 1.2.27beta01
Technical Details:
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)
It is believed that 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). The vendor of the
library is not currently 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.
CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1382>
CVE-2008-1382
Disclosure Timeline:
2008-04-05: Contacted libpng maintainers
2008-04-05: Vendor confirms
2008-04-05: Verification of vendor suggested patch
2008-04-12: libpng-1.2.27beta01 released
2008-04-12: libpng project advisory released
2008-04-12: Advisory release
ADDITIONAL INFORMATION
The information has been provided by <mailto:lcars@ocert.org> Andrea
Barisani.
The original article can be found at:
<http://www.ocert.org/advisories/ocert-2008-003.html>
http://www.ocert.org/advisories/ocert-2008-003.html
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
