Re: Latest libpng Release

It  is possible to write a libpng application that is vulnerable to the
PLTE overrun
bug (CVE-8126). I don't actually know of any application that does the
following:

    1. Reads IHDR
    2. Cares about optimizing memory, so computes maximum PLTE length M
         from bit_depth
    3. Allocates memory with room for M palette entries
    4. Reads PLTE into the libpng-allocated 256-entry palette
    5. Does not care about memory enough to calculate required storage space
        from the libpng-returned palette length, which is frequently much
smaller
        than 2^bit_depth but might be larger, by accident, malevolence, or
fuzzing
    6. Copies L palette entries from (4) into (3), writing out-of-bounds if
M < L

The situation was worse in libpng-1.0.7 and earlier, when libpng wrote the
palette directly into a user-supplied memory block.  Anyone still using
libpng
1.0.7 is vulnerable to dozens of other security problems that have arisen
over
the past 15 years since 1.0.7 was released.

Glenn



On Sun, Nov 15, 2015 at 11:48 AM, John Bowler <
[email protected]> wrote:

> Security announcements are on the png-mng-implement list as they are
> specific to libpng (well, I guess there could be a security issue in the
> PNG spec itself, in which case it would be here, but the issue in question
> is specific to libpng.)  There is a CVE, Glenn posted the number on
> png-mng-implement.
>
> John Bowler
> ​
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> png-mng-misc mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc
>
>

------------------------------------------------------------------------------

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc