A memory leak was found in the way libpng processed malformed Portable Network Graphics (PNG) images with Physical Scale (sCAL) extension. A remote attacker could create a specially-crafted PNG image and trick the local user into opening it in an application, using the libpng library, leading to denial of service (relevant libpng-based application crash). References: [1] http://www.libpng.org/pub/png/libpng.html CVE Request: [2] http://www.openwall.com/lists/oss-security/2010/06/28/2
This issue affects the versions of the libpng package, as shipped with Red Hat Enteprise Linux 3, 4, and 5. This issue affects the versions of the libpng package, as shipped with Fedora release of 12 and 13.
*** Bug 608642 has been marked as a duplicate of this bug. ***
A defense for applications that don't need or want the sCAL chunk is to use the png_set_keep_unknown_chunks() mechanism to ignore it. See Mozilla's libpr0n/decoders/png or ImageMagick and GraphicsMagick's coders/png.c, and pngcrush for examples of this. It's a good idea for applications to do this because it reduces resources consumed in reading a PNG, and it reduces their attack surface by making the application invulnerable to future vulnerabilities in known but unused chunks such as sCAL.
CVE identifier of CVE-2010-2249 has been assigned to this.
Created libpng tracking bugs for this issue Affects: fedora-all [bug 609161]
Created mingw32-libpng tracking bugs for this issue Affects: fedora-all [bug 609162]
Looks like this is the upstream commit to fix this issue: http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=90cfcecc09febb8d6c8c1d37ea7bb7cf0f4b00f3#patch20
This also looks like it would affect libpng10, looking quickly at the code.
(In reply to comment #9) > This also looks like it would affect libpng10, looking quickly at the code. Yes, it does. Upstream has declared end-of-life for libpng10 and does not plan any more updates, even for security, as announced back in February. If that is a hardship, you can complain to png-mng-implemement at lists.sf.net, explain why you still need libpng10, and we might revisit the decision. We also plan to abandon libpng12 at the end of 2010.
(In reply to comment #8) > Looks like this is the upstream commit to fix this issue: > > http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=90cfcecc09febb8d6c8c1d37ea7bb7cf0f4b00f3#patch20 That is an upstream "workaround" for the bug which was removed in a later commit. Our "git" commits show much of our work-in-progress, and there are 4 or 5 commits involved in solving this bug. The actual fix can be found by diffing pngpread.c from libpng-1.4.2 and 1.4.3.
(In reply to comment #8) > Looks like this is the upstream commit to fix this issue: > > http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=90cfcecc09febb8d6c8c1d37ea7bb7cf0f4b00f3#patch20 Yes. This commit contains the changes to pngrutil.c that fix the sCAL chunk memory leak.
(In reply to comment #11) > (In reply to comment #8) > That is an upstream "workaround" for the bug which was removed in a later > commit. Our "git" commits show much of our work-in-progress, and there are > 4 or 5 commits involved in solving this bug. The actual fix > can be found by diffing pngpread.c from libpng-1.4.2 and 1.4.3. Sorry, this comment is about the other bug (the extra-row problem).
libpng-1.2.44-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/libpng-1.2.44-1.fc13
libpng-1.2.44-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libpng-1.2.44-1.fc12
(In reply to comment #10) > Yes, it does. Upstream has declared end-of-life for libpng10 and does > not plan any more updates, even for security, as announced back in > February. If that is a hardship, you can complain to png-mng-implemement at > lists.sf.net, explain why you still need libpng10, and we might revisit the > decision. > > We also plan to abandon libpng12 at the end of 2010. We have libpng10 packages in Red Hat Enterprise Linux 3 and 4, used by things like gnome-libs (both) and Gtk-Perl, gimp (RHEL3-only), so we have to support libpng10 until those distributions reach end-of-life. It isn't necessarily a hardship, but other vendors may be in the same position with regards to supporting libpng10 and libpng12 (we will be supporting libpng12 for many years to come yet). Abandoning libpng12 at the end of this year might be something we should bring up (perhaps some kind of maintenance for security issues alone). Thanks for that information.
libpng-1.2.44-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.44-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2010:0534 https://rhn.redhat.com/errata/RHSA-2010-0534.html
libpng10-1.0.54-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
mingw32-libpng-1.2.44-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
mingw32-libpng-1.2.44-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.