Quoting Secunia advisory SA35346: http://secunia.com/advisories/35346/ A vulnerability has been reported in libpng, which can be exploited by malicious people to disclose potentially sensitive information. The vulnerability is caused due to an error when processing 1-bit interlaced images. This can be exploited to disclose uninitialised memory via specially crafted images having widths that are not divisible by 8. The vulnerability is reported in versions prior to 1.2.37.
Upstream page - http://www.libpng.org/pub/png/libpng.html - contains a rather confusing vulnerability warning: Vulnerability Warning Jeff Phillips reported that several versions of libpng through 1.2.35 contain an uninitialized-memory-read bug that may have security implications. Specifically, 1-bit (2-color) interlaced images whose widths are not divisible by 8 may result in several uninitialized bits at the end of certain rows in certain interlace passes being returned to the user. An application that failed to mask these out-of-bounds pixels might display or process them, albeit presumably with benign results in most cases. This bug may be fixed in version 1.2.36, released 7 May 2009, but the correct fix is in version 1.2.37, released 4 June 2009. Going though 1.2.35 -> 1.2.36 and 1.2.36 -> 1.2.37 diffs, this probably refers to the following changes: Changes in 1.2.36: +version 1.2.36beta02 [March 21, 2009] + Use png_memset() after png_malloc() of big_row_buf when reading an + interlaced file, to avoid a possible UMR. http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=85f7d0a8d5f45176d8f200e59b0d3002ff0f445d#patch26 Changes in 1.2.37: +version 1.2.37beta01 [May 12, 2009] + Fixed inconsistency in pngrutil.c, introduced in libpng-1.2.36. The + memset() was using "png_ptr->rowbytes" instead of "row_bytes", which + the corresponding png_malloc() uses (Joe Drew). http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=549a5101e7d59bec9af1a4d90afe714ceff5c5dd
Created attachment 347014 [details] 1.2.36 change Local copy of: http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=85f7d0a8d5f45176d8f200e59b0d3002ff0f445d#patch26
Created attachment 347015 [details] 1.2.37 change Local copy of: http://libpng.git.sourceforge.net/git/gitweb.cgi?p=libpng/libpng;a=commitdiff;h=549a5101e7d59bec9af1a4d90afe714ceff5c5dd
mingw32-libpng-1.2.37-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/mingw32-libpng-1.2.37-1.fc10
mingw32-libpng-1.2.37-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/mingw32-libpng-1.2.37-1.fc11
mingw32-libpng packages all done.
Calling this a security issue seems like a bit of a stretch. You can only read portions of individual bytes, you can't control very well which bytes those are, and the whole thing depends on the application's display code being seriously buggy (i.e. showing garbage pixels on the right side of an image).
(In reply to comment #7) > Calling this a security issue seems like a bit of a stretch. Yeah, that was reaction too, when seeing upstream announcement. > You can only read portions of individual bytes, you can't control very > well which bytes those are, and the whole thing depends on the > application's display code being seriously buggy (i.e. showing garbage > pixels on the right side of an image). I believe applications displaying images using libpng were not really assumed attack vector, as those can only show those leaked bytes to the user running application, so that case is non-issue. I guess they may have assumed some automated image processing (such as image conversion using ImageMagick's convert, or CUPS printing) as a vector, though even without checking if any such application can return leaked bytes in some output attacker can see and use, the leak seem rather limited, not easily predictable and not too likely to yield any valuable data. Have you already looked into what application must do wrong to process those garbage pixels at all?
Well, it would have to have a bug that causes it to process whole bytes (groups of 8 pixels) without regard to the declared image width. That seems unlikely to escape notice for long so far as "display" actions go. I suppose the most plausible route for an information leak is if the bytes get shoved directly into some other image file (either an output PNG or some other format with similar representational details), and then the attacker manages to get access to that file. I think we've previously decided that bugs in PNG-writing applications aren't really grounds for security responses, and this would effectively be in that category.
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-2042 to the following vulnerability: Name: CVE-2009-2042 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2042 Assigned: 20090612 Reference: CONFIRM: http://www.libpng.org/pub/png/libpng.html Reference: BID:35233 Reference: URL: http://www.securityfocus.com/bid/35233 Reference: SECUNIA:35346 Reference: URL: http://secunia.com/advisories/35346 Reference: VUPEN:ADV-2009-1510 Reference: URL: http://www.vupen.com/english/advisories/2009/1510 Reference: XF:libpng-interlaced-image-info-disclosure(50966) Reference: URL: http://xforce.iss.net/xforce/xfdb/50966 libpng before 1.2.37 does not properly parse 1-bit interlaced images with width values that are not divisible by 8, which causes libpng to include uninitialized bits in certain rows of a PNG file and might allow remote attackers to read portions of sensitive memory via "out-of-bounds pixels" in the file.
libpng-1.2.37-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libpng-1.2.37-1.fc10
libpng-1.2.37-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/libpng-1.2.37-1.fc9
libpng-1.2.37-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/libpng-1.2.37-1.fc11
mingw32-libpng-1.2.37-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
mingw32-libpng-1.2.37-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.37-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.37-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
libpng-1.2.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.
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
All children bugs have been closed, parent is no longer needed.