Some vulnerabilities have been reported in libpng, which can be exploited by malicious people to cause a DoS (Denial of Service). 1) Certain errors within libpng, including a logical NOT instead of a bitwise NOT in pngtrtran.c, an error in the 16bit cheap transparency extension, and an incorrect use of sizeof() may be exploited to crash an application using the library. 2) Various out-of-bounds read errors exist within the functions "png_handle_pCAL()", "png_handle_sCAL()", "png_push_read_tEXt()", "png_handle_iTXt()", and "png_handle_ztXt()", which may be exploited by exploited to crash an application using the library. The vulnerabilities are reported in versions prior to 1.2.21. Solution: Update to version 1.2.21.
Base-system, please advise.
I asked on #-dev whether I should file this bug, Cardoe told me I should. A few minutes later he noticed that the bugs have been introcued in 1.2.19, so our latest stable version should be invulnerable. Closing, sorry for the noise (for the second time even).
http://sourceforge.net/mailarchive/forum.php?thread_name=3.0.6.32.20071004082318.012a7628%40mail.comcast.net&forum_name=png-mng-implement Appears to be the discussion on the issue. They introduced at least one new issue into 1.2.21 via bug #194864. Right now we have 1.2.21-r2 in the tree which patches the issue discussed at http://sourceforge.net/mailarchive/forum.php?thread_name=47067C84.7010205%40playstation.sony.com&forum_name=png-mng-implement However, the patch doesn't look right to me and a user is still having issues.
I believe only one of the security issues was introduced in 1.2.19, the other existed before hand as well.
*** Bug 195387 has been marked as a duplicate of this bug. ***
latest version in the tree is stable for everyone now
(In reply to comment #4) > I believe only one of the security issues was introduced in 1.2.19, the other > existed before hand as well. cardoe, which of them?
I don't know exactly right now. I looked at the code on Tuesday and found one of the CVE's only really applied to .19 and higher. However there's still 2 other security issues which affect all releases of 1.2.x so it doesn't matter much. libpng's official site just says versions before 1.2.22 are vulnerable. Just looking at some of the patches Mike and I had to apply to 1.2.21 and looking at the diff between 1.2.21, they fixed a lot of code that someone should be ashamed of writing. I'd feel better if we stabilized 1.2.22 and just went with that as our security release rather then backport stuff to 1.2.21.
(In reply to comment #8) > I'd feel better if we stabilized 1.2.22 and just > went with that as our security release rather then backport stuff to 1.2.21. If you feel that stabilization of .21 introduced or might introduce regressions or .22 is more suited for current stable, we can do this here.
To sum up the issues fixed here: CVE-2007-5269: Certain chunk handlers in libpng before 1.0.29 and 1.2.x before 1.2.21 allow remote attackers to cause a denial of service (crash) via crafted (1) pCAL (png_handle_pCAL), (2) sCAL (png_handle_sCAL), (3) tEXt (png_push_read_tEXt), (4) iTXt (png_handle_iTXt), and (5) ztXT (png_handle_ztXt) chunking in PNG images, which trigger out-of-bounds read operations. CVE-2007-5268: pngrtran.c in libpng before 1.0.29 and 1.2.x before 1.2.21 use (1) logical instead of bitwise operations and (2) incorrect comparisons, which might allow remote attackers to cause a denial of service (crash) via a crafted PNG image. CVE-2007-5266: Off-by-one error in ICC profile chunk handling in the png_set_iCCP function in pngset.c in libpng before 1.0.29 beta1 and 1.2.x before 1.2.21 beta1 allows remote attackers to cause a denial of service (crash) via a crafted PNG image that prevents a name field from being NULL terminated. Plus: "another crash bug (related to the ICC-profile chunk) remains to be fixed in version 1.2.22."
I vote NO.
that's A3 so no need to vote here... GLSA request filed.
(In reply to comment #9) > (In reply to comment #8) > > I'd feel better if we stabilized 1.2.22 and just > > went with that as our security release rather then backport stuff to 1.2.21. > > If you feel that stabilization of .21 introduced or might introduce regressions > or .22 is more suited for current stable, we can do this here. Cardoe?
I was on vacation so that's why the non-response. But yes, I think 1.2.22 should be stabled instead of 1.2.21 since there technically are vulnerabilities still in 1.2.21.
Okay. Arch teams, please stabilise media-libs/libpng-1.2.22, targets are: "alpha amd64 arm hppa ia64 m68k mips ppc ppc64 s390 sh sparc ~sparc-fbsd x86 ~x86-fbsd".
Adding arches
Sparc stays ahead of the curve and is stable.
removing solar at his request
Stable on x86
Stable for HPPA.
alpha/ia64 stable
ppc64 stable
amd64 done.
ppc stable
GLSA was already filed.
GLSA 200711-08