Bug#650601: [png-mng-implement] Lack of security in libpng 1.2
On Sat, Feb 18, 2012 at 10:42:34PM -0800, firstname.lastname@example.org wrote:
>There are a lot of negatives in the following sentence, bear with me,
>or believe me and take note of the final sentence before my signature
>in this message.
>Glenn has pointed out to me that even though libpng 1.2.46 never
>assigns the 'default' to the limit variable in png_struct (which, in
>fact, does not exist in 1.2) the code in pngread.c never actually
>checks that non-existent variable because the checking code is
>protected by another random sequence of characters; from
> if (png_ptr->user_chunk_malloc_max &&
> (prefix_size + expanded_size >= png_ptr->user_chunk_malloc_max - 1))
># ifdef PNG_USER_CHUNK_MALLOC_MAX
> if ((PNG_USER_CHUNK_MALLOC_MAX > 0) &&
> prefix_size + expanded_size >= PNG_USER_CHUNK_MALLOC_MAX - 1)
>I.e. "PNG_SET_CHUNK_MALLOC_LIMIT_SUPPORTED" is another variant on the
>always-undefined macro from pngread.c "PNG_SET_USER_CHUNK_MALLOC_MAX";
>so far as I can see short of an explicit -D in CFLAGS there is no way
>to get these macros defined in a build of libpng 1.2
>So... in fact libpng-1.2 as it currently stands has no way of
>preventing attacks based on the relatively simple approach revealed by
>Google of sending a PNG with an unnaturally large iCCP.
>I simply suggest that no one uses libpng 1.2; it's not safe.
>John Bowler <email@example.com>
The message above is part of a discussion in the libpng development
mailing list about the *lack* of security of libpng 1.2, after the last
vulnerability was discovered by the chrome folks.
For more details see
So, the message is to move away from libpng 1.2 in Debian as soon as we