A vulnerability has been reported in libpng, which can be exploited by malicious people to potentially compromise an application using the library. The vulnerability is caused due to an integer overflow error within the "png_decompress_chunk()" function (pngrutil.c) when uncompressing certain chunks, which can be exploited to cause a heap-based buffer overflow. Successful exploitation may allow execution of arbitrary code but requires tricking the user into opening a specially crafted PNG file. Solution Do not open PNG files from untrusted sources. Currently un-patched upstream
Created attachment 302317 [details, diff] Fix from mozilla.org The attached patch is (except for changes in version numbers) the full diff between firefox 10.0.1 an 10.0.2. Except for a missing cast and some whitespace issues this patch applies against libpng-1.5.8 for me.
Should the priority of this bug be raised? Secunia only labels it "Moderately critical" == 3 out of 5, but the browser vendors think different. Mozilla: "Critical" == 4 out of 4 http://www.mozilla.org/security/announce/2012/mfsa2012-11.html Chrome: "High" == 3 out of 4 http://googlechromereleases.blogspot.com/2012/02/chrome-stable-update.html (And they gave $1337 for this bug instead of $1000 for the other "High" bugs) And want's more: Bumping your browser ebuild (to firefox-10.0.2 or equivalent) will not safe you, because the ebuilds will use the system libpng and not the fixed ones that are bundled with the browsers: chromium-ebuild: -Duse_system_libpng=1 firefox-ebuild: mozconfig_annotate '' --with-system-png
Torsten, the severity is set according to Gentoo's Vulnerability Policy [1], not from other sources. @base-system: I didn't see anything from upstream on this yet, but Debian has released patches for 1.2.46 [2] and 1.5.8 [3]. [1] http://www.gentoo.org/security/en/vulnerability-policy.xml [2] http://patch-tracker.debian.org/patch/series/dl/libpng/1.2.46-5/02-660026-CVE-2011-3026.patch [3] http://patch-tracker.debian.org/patch/series/dl/libpng/1.5.8-1/02-660026-CVE-2011-3026.patch
Sorry about the priority suggestion. I messed up comparing Bugzillas priority field (still normal for this bug) with the average rating from Secunia. But I ignored the A2 rating. Thanks for the link to the Vulnerability Policy... Real cause for this comment: I think Debian messed up their patch. Patch from Mozilla: + text = (png_charp)png_malloc_warn(png_ptr, prefix_size + expanded_size + 1); Patch from Debian (the one against 1.5.8): + png_charp text = (png_charp)png_malloc_warn(png_ptr, + prefix_size + expanded_size + 1); They declare a new local variable so the allocation will never succeed. Gcc also thinks that is strange: # gcc -Wall -c -O3 pngrutil.c pngrutil.c: In function ‘png_decompress_chunk’: pngrutil.c:467:23: warning: unused variable ‘text’
1.5.9 added to CVS and it can be stabilized.
Thanks! Arches, please test and mark stable: =media-libs/libpng-1.5.9 Target KEYWORDS="alpa amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
amd64 stable
x86 stable
CVE-2011-3026 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3026): Integer overflow in libpng, as used in Google Chrome before 17.0.963.56, allows remote attackers to cause a denial of service or possibly have unspecified other impact via unknown vectors that trigger an integer truncation.
Stable for HPPA.
From the libpng homepage at http://www.libpng.org/pub/png/libpng.html: > All branches of libpng prior to versions 1.5.9, 1.4.9, 1.2.47, and > 1.0.57, respectively, fail to correctly validate a heap allocation in > png_decompress_chunk(), which can lead to a buffer-overrun and the > possibility of execution of hostile code on 32-bit systems. This > vulnerability has been assigned ID CVE-2011-3026 and is fixed in > version 1.5.9, released 18 February 2012. =media-libs/libpng-1.2.47 was already stabilized on x86/amd64 (thanks, Samuli).
ppc done
Stable on alpha.
ppc64 done
arm stable
ia64/m68k/s390/sh/sparc stable
thanks, everyone. Already in GLSA request.
This issue was resolved and addressed in GLSA 201206-15 at http://security.gentoo.org/glsa/glsa-201206-15.xml by GLSA coordinator Sean Amoss (ackle).