Red Hat Bugzilla – Bug 468990
CVE-2008-6218 libpng: "png_handle_tEXt()" memory leak vulnerability - DoS (memory exhaustion) via a crafted PNG file.
Last modified: 2016-03-04 06:02:16 EST
Secunia reports in SA32418:
A vulnerability has been reported in libpng, which can be exploited by
malicious people to cause a DoS (Denial of Service).
The vulnerability is caused due to a memory leak error within the
"png_handle_tEXt()" function in pngrutil.c. This can be exploited to
potentially exhaust all available memory via a specially crafted PNG image.
The vulnerability is reported in version 1.2.32. Other versions may also be
Fixed in version 1.2.33rc02.
libpng10-1.0.41-1.fc9 has been submitted as an update for Fedora 9.
libpng10-1.0.41-1.fc8 has been submitted as an update for Fedora 8.
Fedora 10 build of libpng10 1.0.41 submitted for inclusion in F10 Final:
libpng10-1.0.41-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.41-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
I believe all currently-supported releases have fixes for this (libpng10 and libpng) in the stable updates repos now.
(In reply to comment #7)
> I believe all currently-supported releases have fixes for this (libpng10 and
> libpng) in the stable updates repos now.
Currently-supported Fedora releases I mean...
Common Vulnerabilities and Exposures assigned an identifier CVE-2008-6218 to
the following vulnerability:
Memory leak in the png_handle_tEXt function in pngrutil.c in libpng
before 1.2.33 rc02 and 1.4.0 beta36 allows context-dependent attackers
to cause a denial of service (memory exhaustion) via a crafted PNG
It should be noted that Red Hat is not considering this flaw to be a security issue.
None of the applications that use this library are at any risk of causing a denial-of-service in a meaningful way.
Client applications are required to reload a bad image multiple times in order to trigger this flaw, we do not consider a crash of a user application to be a security flaw.
None of the services that use libpng do so in a long running manner. Our investigation showed that services tend to fork off short lived children to handle these functions, which would not affect the parent process if there was indeed a memory leak.
We do not consider a crash of a client application linked to libpng to be a security issue. None of the applications that use libpng are at any risk of causing a denial of service in a meaningful way.