[Png-mng-security] vulnerability in png_decompress_chunk()
glennrp at comcast.net
glennrp at comcast.net
Fri Feb 5 13:21:27 UTC 2010
----- Original Message -----
From: "John Bowler" <jbowler at frontiernet.net>
> This does mean that you will be changing the png_struct or png_info
> structure in 1.4 (as in the current 1.4.1beta06 - adding a member to
> a structure visible in the ABI; at extra 4 bytes at the end of
> png_struct). IRC that happened several times in 1.2.
Still waiting for a definitive answer to whether it's OK to
do this any more without a minor version bump (i.e., 1.4.0 to
1.5.0 and libpng14.so to libpng15.so).
For 1.4.1beta07 I am planning to implement essentially what's in
beta06, but with the opportunity for the downstream libpng
builder to impose default limits on the maximum size and
number of compressed chunks via #define and for the application
writer to override the limits via "png_set_*()" functions. The
defaults set in our distribution will be 0 meaning unlimited.
That includes the get|set functions and a new png_struct member
to hold the malloc limit (1.4.0 already has one for the chunk
For 1.2.43 I am planning to implement the same but without
the get|set functions and without a new member in png_struct.
The memory limit will be a constant that can be defined by
the downstream libpng builder, default 0, meaning unlimited.
I don't see a way of imposing a limit on the number of
compressed chunks because that requires a counter in the
Libpng-1.4.1 and 1.2.43 (and 1.0.53) will use the fast
two-pass png_decompress_chunk() that measures the
chunk before allocating memory for it.
I have posted patches for Firefox/Mozilla to the
bugzilla.mozilla.org bug #497056 along these lines,
to replace the png_decompress_chunk() function with
the two-pass function in the embedded library and a
fixed 4-MB maximum on the size of decompressed iCCP
chunks. If Firefox (or other gecko-based application)
is built with the system libpng older than 1.4.1, then
it uses a replacement malloc_fn() to impose the 4MB
limit on the decompressed iCCP chunk size
and increased the size of zbuf_size for iCCP chunk
decompression to 32k, That's not an ideal solution
but I don't have any other ideas.
In libpng-1.4.0, 0x7fffffff means an unlimited
number of chunks allowed, but "0" seems simpler
to implement and to explain. It doesn't really make
any practical difference so I think it's OK to make
this change in 1.4.1.
More information about the png-mng-security-archive