[png-mng-misc] Question about the fix for CVE-2014-9495

[Na P. <pe...@cn...>]

Hi John,
I checked png_check_IHDR code(in pngset.c) in 1.2.35,  the code is almost 
the same as libpng1.4.  So we are not impacted since we didn't call 
png_set_user_limits to change the image width limitation?


On Wednesday, January 28, 2015, Xing XZ Zhou <xz...@cn...> wrote:
Hi Jonh, since our older product used libpng1.2.7 and libpng1.2.35, I also 
want to ask you that whether libpng1.2.* is impacted by these two CVEs? 
And if it does, is there any plan to fix them in 1.2.*? 
====================================

I don't know if Glenn is even issuing security fixes for 1.2 at this 
point, however in this case a problem can only arise if the application 
changes (removes) the default limit on the width of the PNG being read.  
Consequently this isn't a major security issue from the libpng viewpoint 
because libpng 1.2 (the latest version) isn't vulnerable by default and it 
is very unlikely that an app would turn off the width checking.

For any unmodified version of libpng, not just those in 1.2, examine the 
code in png_check_IHDR, which is somewhere around line 1000 of png.c, and 
look for a check on 'width' (one of the parameters to png_check_IHDR).  If 
that check will limit the image width to something significantly less than 
a billion pixels, less than 1/32 billion to be safe, then there is no 
problem.  With a default build this probably means looking at the app code 
too, to see whether it calls png_set_user_limits.

In general in 1.2 check the definition of PNG_USER_WIDTH_MAX, since it 
trumps the app value from png_set_user_limits.

1.2.35: the png_check_IHDR code is in png_set_IHDR (pngset.c) in this, six 
year old, version of 1.2.  It does basically the same thing as 1.2.51 
however PNG_USER_WIDTH_MAX does not trump the app setting, so you must 
check each app.

1.2.7: this minor release, from 2004, is substantially the same as 1.2.35 
minor release in regard to this issue.

However, using a release from over 10 years ago without active and 
continuous maintenance is obviously something that will result in dropped 
fixes for known issues.  Therefore, assuming you have been maintaining 
1.2.7, you actually have a fork which has diverged through 10 years of bug 
fixes from what was originally released and anything I say about the 
original distribution is irrelevant.

John Bowler