the library provides 2 calls png_chunk_error and png_chunk_warning for default error and warning messages handling. Inside the code a fixed size buffer is used and 64 bytes are used to store the caller supplied message. But there are no bounds checking and this limitation is not documented. Programs linked against libpng may crash or even execute arbitrary code if the caller message is dependent on external inputs. See Debian : http://www.debian.org/security/2004/dsa-498 Mandrake : http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-2004:040 Here is Mandrake's patch : --- libpng-1.2.5/pngerror.c.can-2004-0421 2002-10-03 05:32:27.000000000 -0600 +++ libpng-1.2.5/pngerror.c 2004-04-29 09:26:18.000000000 -0600 @@ -135,10 +135,12 @@ buffer[iout] = 0; else { + png_size_t len = strnlen(error_message, 63); + buffer[iout++] = ':'; buffer[iout++] = ' '; - png_memcpy(buffer+iout, error_message, 64); - buffer[iout+63] = 0; + png_memcpy(buffer+iout, error_message, len); + buffer[iout+len] = 0; } }
Confirmed -- denial of service attack is probably the highest risk here. no metadata.xml or recent maintainer : we need someone to apply the Mandrake patch to libpng-1.2.5-r4 (slot 1.2) and libpng-1.0.15-r1 (slot 1.0) and rev-bump the ebuilds. -K
Created attachment 30917 [details, diff] files/libpng-1.2.5-gentoo.diff New diff file for 1.2.5 including the patch Tested : applies OK, compiles OK, works OK
Created attachment 30918 [details, diff] files/libpng-1.0.15-gentoo.diff New diff file for libpng-1.0.15 Tested : Applies OK, Compiles OK, Works ? (I have no application using libpng1) ebuilds libpng-1.2.5 and libpng-1.0.15 should be rev-bumped so that the security fix appears in normal upgrade process
Koon, Updated in portage. All arches have libpng-1.2.5-r4.ebuild marked stable already. KEYWORDS="x86 ppc sparc mips alpha arm hppa amd64 ia64 ppc64 s390" Added both patches however. It's upto you if you want to call for arch testing or not. I don't think you/we need to in this case.
Can someone rev-bump to 1.2.5-r5 and 1.0.15-r2 so that the new diff file gets taken into account in the normal upgrade process ?
Ready for a GLSA
GLSA 200405-06