1368276 - Potential integer overflow in BootAnimation.cpp with large PNG image

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, enhancement)

Description

[Glenn Randers-Pehrson]

CVE-2016-5735 describes a potential integer overflow in pngquant, when it attempts to allocate a buffer for the entire image.  The PNG format limits width and height to 2^31-1, and the number of bytes per pixel can be as large as 8.  The product of width*height*bytespp can exceed 2^64, leading to integer overflow, even on 64-bit platforms.  While the CVE was about a particular libpng applicaton, all libpng applications that attempt to allocate an image buffer are susceptible to this vulnerability, which is disclosed in the pngquant patch and in the forthcoming libpng-1.6.30 release. Our BootAnimation.cpp suffers from this potential overflow.  We should apply the same fix to BootAnimation.cpp as used in pngquant and in the libpng distribution.

Comment 1

[Glenn Randers-Pehrson]

Attachment: v00-1368276-bootanimation

Comment 2

[Glenn Randers-Pehrson]

References:
CVE-2016-5735: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5735
https://github.com/glennrp/libpng/commit/53f22aed41a1cb0d2d23e8085c718b0601384640
https://github.com/glennrp/libpng/commit/b99308a33c77ad65a5d016b2097cebc2fee045dd

Comment 3

[Glenn Randers-Pehrson]

Attachment: v01-1368276-bootanimation

Removed "return" statement that cannot be reached after png_error().

Comment 4

[Glenn Randers-Pehrson]

Observe that the recommended check is equivalent to what we already do in image/decoders/nsPNGDecoder.cpp at line 780.

Comment 5

[Glenn Randers-Pehrson]

Please submit a tryserver run.

Comment 6

[Ryan VanderMeulen (PTO, back July 27)]

There's no point in running this through Try. FxOS is dead and we don't even have CI for it anymore. I'm inclined to WONTFIX this and open it up - what are your thoughts, Paul?

Comment 7

[Ryan VanderMeulen (PTO, back July 27)]

Opened up once affected Firefox branches are updated with the new libpng version, of course.

Comment 8

[Glenn Randers-Pehrson]

There's no dependence upon libpng versions.

Comment 9

[Glenn Randers-Pehrson]

I'm fine with WONTFIX, given comment #6

Comment 10

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Yep, I think that's appropriate. I'm not sure what timeframe comment 7 is referring to, so I'll leave this closed for now.

Comment 11

[Glenn Randers-Pehrson]

comment #7 is, I suppose, referring to libpng-1.6.30 which has fixes for this vulnerability in several applications distributed with libpng but nothing in libpng proper, because libpng itself is not vulnerable.  I don't know when libpng-1.6.30 will be out because there are no pressing reasons for a quick release.

Comment 12

[Ryan VanderMeulen (PTO, back July 27)]

Yeah, I just don't want to see us accidentally 0-day others by making this bug public too early. Let us know when we're good to do so :)

Comment 13

[Glenn Randers-Pehrson]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)
> Yeah, I just don't want to see us accidentally 0-day others by making this
> bug public too early. Let us know when we're good to do so :)

The vulnerability was publicly exposed in the pnqquant git repository nearly a year ago, and in the
libpng-1.6.30beta series, the libpng mailing list, and CVE-2016-5735 recently.  If you'd rather wait
until libpng-1.6.30 is released, OK, but I do not see a need for that.