Bug 441839 - (CVE-2008-1382) CVE-2008-1382 libpng unknown chunk handling flaw
CVE-2008-1382 libpng unknown chunk handling flaw
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,source=vendorsec,reported=...
: Reopened, Security
: 445487 (view as bug list)
Depends On: 487164 487165 487166 487167 487168 487169 487170 487171 487172 537849 802164
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-10 10:40 EDT by Josh Bressers
Modified: 2013-05-08 16:05 EDT (History)
6 users (show)

See Also:
Fixed In Version: 1.2.29-1.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-08 16:05:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed upstream patch (7.63 KB, patch)
2008-04-10 10:44 EDT, Josh Bressers
no flags Details | Diff
Local copy of libpng upstream advisory text (1.95 KB, text/plain)
2008-04-15 03:37 EDT, Tomas Hoger
no flags Details

  None (edit)
Description Josh Bressers 2008-04-10 10:40:54 EDT
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.
Comment 4 Josh Bressers 2008-04-10 10:44:52 EDT
Created attachment 302000 [details]
Proposed upstream patch
Comment 5 Josh Bressers 2008-04-10 10:47:10 EDT
Upon inspecting the Red Hat Enterprise Linux and Fedora source, it appears that
only ImageMagick in RHEL5 and Fedora use this functionality in libpng.
Comment 6 Tom Lane 2008-04-10 13:54:22 EDT
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.
Comment 7 Josh Bressers 2008-04-10 20:21:58 EDT
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.
Comment 8 Tomas Hoger 2008-04-14 02:42:18 EDT
Public now via:

http://www.ocert.org/advisories/ocert-2008-003.html
http://libpng.sourceforge.net/Advisory-1.2.26.txt

Lifting embargo.
Comment 9 Tomas Hoger 2008-04-14 02:49:23 EDT
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.
Comment 10 Tomas Hoger 2008-04-15 03:37:08 EDT
Created attachment 302414 [details]
Local copy of libpng upstream advisory text
Comment 11 Tomas Hoger 2008-04-15 03:38:11 EDT
Tom, Paul, feel free to include a patch in future Fedora libpng/libpng10
packages updates once you'll be doing them.  Thanks!
Comment 12 Paul Howarth 2008-04-30 10:27:36 EDT
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.
Comment 13 Tom Lane 2008-05-07 00:58:26 EDT
*** Bug 445487 has been marked as a duplicate of this bug. ***
Comment 15 Fedora Update System 2008-05-28 22:34:33 EDT
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.
Comment 16 Fedora Update System 2008-05-28 22:49:47 EDT
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.
Comment 17 Fedora Update System 2008-05-28 22:50:20 EDT
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.
Comment 18 Fedora Update System 2008-06-03 03:30:00 EDT
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.
Comment 19 Fedora Update System 2008-06-03 03:34:12 EDT
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.
Comment 20 Fedora Update System 2008-06-03 03:36:14 EDT
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.
Comment 21 Tom Lane 2009-02-25 16:52:13 EST
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?
Comment 22 Tom Lane 2009-02-25 17:40:59 EST
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.
Comment 36 Vincent Danen 2013-05-08 16:05:08 EDT
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

Note You need to log in before you can comment on or make changes to this bug.