oss-security - Re: libpng non issue

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [month] [year] [list]

Date: Sun, 18 Jan 2009 19:55:22 +0100
From: Nico Golde <oss-security+ml@...lde.de>
To: oss-security@...ts.openwall.com
Subject: Re: libpng non issue

Hi,
* Josh Bressers <bressers@...hat.com> [2009-01-10 15:41]:
> I figured I'd put this out in the open before it gets picked up and causes
> confusion.
> 
> The libpng main page (http://libpng.sourceforge.net/index.html) currently contains
> this:
> 
> UPDATE 18 December 2008: The latest released versions are libpng-1.0.42 and
> libpng-1.2.34. They fix a vulnerability to a possible double-free in
> png_check_keyword() while writing various chunk types.
> 
> This isn't a double free, nor would I consider it a security bug.  Our libpng
> maintainer Tom Lane helped out with this analysis.
> 
> As best as I can tell, this is the bug in question:
> http://sourceforge.net/mailarchive/forum.php?thread_name=4B6F0239C13D0245820603C036D180BC79FBAA%40CABOTUKEXCH01.cabot.local&forum_name=png-mng-implement

Looking at the diff between 1.2.33 and 1.2.34 I also see no 
fix for a double-free vulnerability. The only security 
relevant change I can see is indeed the above issue.

> which results in writing a NULL byte to an arbitrary location in memory.
> 
> Here is what Tom Lane said about this:
> 
>     Some poking around shows that png_check_keyword is called in subroutines
>     that *write* PNG chunks, not ones that read them. So the problem could
>     only manifest in programs that were creating new PNG files and trying
>     to put illegal-per-spec content in them. Also, in typical usage the
>     keywords being checked would be constant strings in the app, thus even
>     less likely to trigger the overlength error. (It seems likely that this
>     code has actually never been executed anywhere, explaining why the bug
>     went undetected.)
> 
> So unless someone sees a flaw in this analysis, Red Hat has no plans to consider this a security flaw.

As this function symbol is exported via the shared library 
what about programs using this function?

Cheers
Nico
-- 
Nico Golde - http://www.ngolde.de - nion@...ber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.