Tavis Ormandy reported: libpng does not correctly handle unknown zero-length chunks, which could result in writing to attacker controlled addresses, depending on how the libpng api is used. In order for this to be an issue, the application in question is going to need to call png_set_keep_unknown_chunks(), which tells libpng not to ignore unknown chunks, but to do something with them. The PNG spec allows for "unknown" chunks, which are ignored by default, but an application could in theory embed some sort of extra data in a png image, then later get it back out via this mechanism. This in turn appears to be how the flawed code in question will get executed. If the application doesn't call png_set_keep_unknown_chunks(), it shouldn't be vulnerable to this problem.
Created attachment 302000 [details] Proposed upstream patch
Upon inspecting the Red Hat Enterprise Linux and Fedora source, it appears that only ImageMagick in RHEL5 and Fedora use this functionality in libpng.
Glenn R-P reports on the png security list that ImageMagick doesn't actually crash, so this may be a low priority issue for our purposes.
Yes, absolutely. If we fix this, it be piggy-backed on a more sever libpng update. it's not worth rolling updates just for this.
Public now via: http://www.ocert.org/advisories/ocert-2008-003.html http://libpng.sourceforge.net/Advisory-1.2.26.txt Lifting embargo.
This issue affects all versions of libpng and libpng10 shipped in Red Hat Enterprise Linux 2.1, 3, 4, and 5 and current Fedora versions. Due to a very low security impact of this flaw (see previous comments and upstream advisory linked in comment #8), we do not plan to release updated libpng and libpng10 packages for Red Hat Enterprise Linux immadiately. This issue may be addressed in future updates of those packages.
Created attachment 302414 [details] Local copy of libpng upstream advisory text
Tom, Paul, feel free to include a patch in future Fedora libpng/libpng10 packages updates once you'll be doing them. Thanks!
I built updated packages of libpng10 1.0.33 for Fedora 7, 8, 9, and devel, and submitted updates for testing for the non-devel branches. I don't think there's any need to push these straight to stable.
*** Bug 445487 has been marked as a duplicate of this bug. ***
libpng10-1.0.37-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
libpng10-1.0.37-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
libpng10-1.0.37-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.29-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.29-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.29-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
After looking more closely at the changes made for this in libpng 1.2.27, I'm not actually convinced that there is any bug here at all. What will happen with a zero chunk length is that png_malloc will return a NULL buffer, png_crc_read will do nothing, and png_free will do nothing because it's handed a NULL. (There's a potential crash in the pre-1.2.27 Borland-specific png_free, but we don't care about that.) The only way that there's actually any problem is if an application-supplied unknown-chunk handler tries to dereference the NULL pointer despite being told there's zero data there. If so, then (1) it's not libpng's bug and (2) the 1.2.27 changes don't prevent the case anyway. Has anyone reproduced an actual problem related to this, other than on a Borland-specific build?
Ah, after looking closer I see the issue: the changes on the read side really are just cosmetic --- they might save a few cycles but I don't think they change the outcome. The bug is actually on the *write* side, where the code to copy a zero-length unknown chunk from the application and into libpng's data structure is wrong. So the problem only occurs if attempting to *write* a zero-length unknown chunk. It could be called a security issue I guess if you suppose the chunk is being copied from a malevolent source PNG, but the argument is pretty thin. Anyway, we might as well fix it as long as we're turning 2009-0040, but I'd put the security impact at somewhere around nil.
Statement: This issue does not affect the version of libpng as shipped with Red Hat Enterprise Linux 3. Updates for affected versions of Red Hat Enterprise Linux can be found here: http://rhn.redhat.com/errata/RHSA-2009-0333.html