[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] libpng non issue
From:       Nico Golde <oss-security+ml () ngolde ! de>
Date:       2009-01-18 18:55:22
Message-ID: 20090118185522.GD22628 () ngolde ! de
[Download RAW message or body]


Hi,
* Josh Bressers <bressers@redhat.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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]