From newt at pobox.com  Sun Jul 20 01:20:32 2008
From: newt at pobox.com (Greg Roelofs)
Date: Sat, 19 Jul 2008 18:20:32 -0700
Subject: [Png-mng-security] Memory Leaks in libpng
In-Reply-To: <487FA2AA.5060506@hoodel.com>
Message-ID: <200807200120.m6K1KWMw003173@bolt.sonic.net>

Kurt Christensen <hoodel at hoodel.com> wrote:

> Greg,

> I have found several places where memory could leak in the libpng src. 
> These all stem from pngrutil.c. I didn't know how to report this. 
> Hopefully you can help.

The png-mng-implement mailing list is usually the best place to report
libpng issues, unless it's a security issue.  This is kind of a borderline
case; in principle, a hostile web site could load itself up with lots of
these images, causing a denial of service in visiting browsers, but there
are many other ways to do the same thing with entirely valid images, such
as loading up the web page with a huge number of very large images.  So
I'd be inclined not to treat this as a security issue.  However, insofar
as others may disagree, I've bcc'd the libpng security list rather than
cc'd the png-mng-implement list.

> Kurt

> In png_handle_iCCP examine
> -------------------------------
>    chunkdata = (png_charp)png_malloc(png_ptr, length + 1);
>    slength = (png_size_t)length;
>    png_crc_read(png_ptr, (png_bytep)chunkdata, slength);

>    if (png_crc_finish(png_ptr, skip))
>    {
>       png_free(png_ptr, chunkdata);
>       return;
>    }
> ---------------------------------------
> If png_crc_read or png_crc_finish encounter a premature end of file, 
> png_error is called with no return, and hence png_free never gets called.
> Similar constructs exist in the following routines, each potentially 
> leaking if the image file is corrupt.
>   png_handle_sPLT
>   png_handle_pCAL
>   png_handle_sCAL
>   png_handle_tEXt
>   png_handle_zTXt
>   png_handle_iTXt
>   png_handle_unknown


Thanks,
-- 
Greg Roelofs          newt at pobox.com           http://pobox.com/~newt/
Newtware, PNG Group, AlphaWorld Map, Yahoo! Search, ...


From cosmin at cs.toronto.edu  Sun Jul 20 02:16:32 2008
From: cosmin at cs.toronto.edu (Cosmin Truta)
Date: Sat, 19 Jul 2008 22:16:32 -0400 (EDT)
Subject: [Png-mng-security] Memory Leaks in libpng
In-Reply-To: <200807200120.m6K1KWMw003173@bolt.sonic.net>
References: <200807200120.m6K1KWMw003173@bolt.sonic.net>
Message-ID: <Pine.LNX.4.64.0807192212540.13085@apps0.cs.toronto.edu>


I agree with Greg, memory leaks are not really security issues, left
alone the fact that they're in iCCP, which browsers that I know of don't
handle.

IMO, this may safely go to png-mng-implement.

Best regards,
Cosmin


On Sat, 19 Jul 2008, Greg Roelofs wrote:

> The png-mng-implement mailing list is usually the best place to report
> libpng issues, unless it's a security issue.  This is kind of a borderline
> case; in principle, a hostile web site could load itself up with lots of
> these images, causing a denial of service in visiting browsers, but there
> are many other ways to do the same thing with entirely valid images, such
> as loading up the web page with a huge number of very large images.  So
> I'd be inclined not to treat this as a security issue.  However, insofar
> as others may disagree, I've bcc'd the libpng security list rather than
> cc'd the png-mng-implement list.


From glennrp at comcast.net  Sun Jul 20 11:59:50 2008
From: glennrp at comcast.net (glennrp at comcast.net)
Date: Sun, 20 Jul 2008 11:59:50 +0000
Subject: [Png-mng-security] Memory Leaks in libpng
Message-ID: <072020081159.6643.488328B6000C2B4D000019F322058891169F9D02020A0409@comcast.net>


 -------------- Original message ----------------------
From: Greg Roelofs <newt at pobox.com>
> Kurt Christensen <hoodel at hoodel.com> wrote:
> 
> > Greg,
> 
> > I have found several places where memory could leak in the libpng src. 
> > These all stem from pngrutil.c.
> > [...]
> > If png_crc_read or png_crc_finish encounter a premature end of file, 
> > png_error is called with no return, and hence png_free never gets called.
> > Similar constructs exist [...]

Have you actually observed the behavior?  It seems to me that
png_free() will be called during the png_destroy_read_struct() that
is supposed to be included by the application in the setjmp()
block.  See example.c and other test programs that are included
in libpng distribution.  If applications fail to clean up there, they will
have worse leaks (the entire png_struct, for example) than this.

Glenn


From glennrp at comcast.net  Sun Jul 20 12:09:08 2008
From: glennrp at comcast.net (glennrp at comcast.net)
Date: Sun, 20 Jul 2008 12:09:08 +0000
Subject: [Png-mng-security] Memory Leaks in libpng
Message-ID: <072020081209.11083.48832AE4000001B600002B4B22058861729F9D02020A0409@comcast.net>


 -------------- Original message ----------------------
From: glennrp at comcast.net
>  It seems to me that
> png_free() will be called during the png_destroy_read_struct() that
> is supposed to be included by the application in the setjmp()
> block.

My mistake.  The local "chunkdata" array is not freed through
that mechanism.

Glenn


From glennrp at comcast.net  Sun Jul 20 20:21:04 2008
From: glennrp at comcast.net (glennrp at comcast.net)
Date: Sun, 20 Jul 2008 20:21:04 +0000
Subject: [Png-mng-security] Memory Leaks in libpng
Message-ID: <072020082021.4739.48839E30000133E10000128322070009539F9D02020A0409@comcast.net>


 -------------- Original message ----------------------
From: Kurt Christensen <hoodel at hoodel.com>
> 
> I have actually observed the behavior in a Purify context. That's how 
> I found it in the first place. Since I am in a crawler application, 
> not a browser application, even small leaks can accumulate to hang 
> the system eventually.

Thanks for this report.

> I performed a kludge/work-around, which modified pngrutil.c and my 
> png_error surrogate. I used two extern flags. One is set in 
> png_handle_<chunk> whenever one of these patterns is encountered, and 
> cleared after the pattern. The other gets set by png_error when the 
> first flag is set, in which case it returns instead of doing the long 
> jump.
> 
> png_handle_<chunk> seeing the second flag set, frees the memory and exits.
> 
> Since this would have to be patched again in any subsequent version 
> of libpng, I thought it better to have the community patch it at the 
> source rather than have me do my work-around, which benefits only me.

I think a more straight-forward approach would be to make the chunkdata
pointer a new member of png_struct, so it could be reliably
freed during the png_read_destroy() process.

Glenn


From glennrp at comcast.net  Mon Jul 21 13:39:45 2008
From: glennrp at comcast.net (Glenn Randers-Pehrson)
Date: Mon, 21 Jul 2008 09:39:45 -0400
Subject: [Png-mng-security] Memory Leaks in libpng
In-Reply-To: <200807200120.m6K1KWMw003173@bolt.sonic.net>
References: <487FA2AA.5060506@hoodel.com>
Message-ID: <3.0.6.32.20080721093945.01540a40@mail.comcast.net>

At 06:20 PM 7/19/2008 -0700, Greg Roelofs wrote:
>Kurt Christensen <hoodel at hoodel.com> wrote:
>
>> Greg,
>
>> I have found several places where memory could leak in the libpng src. 
>> These all stem from pngrutil.c

I think this is fixed in libpng-1.2.30rc02 as well as in libpng-1.0.38rc02
and libpng-1.4.0beta21.  I moved the "chunkdata" pointer into a new
member of the png_struct, and added a line to png_read_destroy() to
make sure it's freed during final cleanup.

The total cost of the fix is an approximately 300 byte increase in the
size of pngrutil.o

Perhaps it would have been better to make png_ptr->chunkdata have
type png_bytep instead of png_charp, but that would have changed
the signature of an exported function.  We could make that change
in libng-1.4.0betaNN, though, if desired.

Glenn