[Png-mng-security] Memory Leaks in libpng

[Greg Roelofs]

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, ...