299445 - zlib buffer overflow

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect)

Description

[Tavis Ormandy]

I've discovered a deflate data stream that causes zlib to overwrite the bounds 
of an array, I believe this to be potentially exploitable under certain 
conditions to execute arbitrary code. Mark Adler, co-author of zlib, has 
provided the detailed explanation and proposed patch attached.

Please try to load the png or php files in the URL field for a testcase.

As mozilla bundles it's own distribution of zlib, I expect this will have to be 
fixed independently of the system zlib.

Comment 1

[Tavis Ormandy]

Attachment: explanation and proposed patch

Comment 2

[Daniel Veditz [:dveditz]]

There doesn't appear to be similar code in our version of zlib (1.1.4), in fact
the stylistic differences are so great it's hard to believe it's from the same
library. Does that mean we're not vulnerable, or just that we need a different
patch?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

hm? the code at least on trunk looks basically identical (I think indentation is
a bit off, so the patch does not apply directly). Did we update zlib on trunk,
but not on branch, maybe?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

https://bugzilla.mozilla.org/show_bug.cgi?id=248644 is when we last updated zlib.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to comment #2)
> our version of zlib (1.1.4)

Oops, I was looking at a branch tree. I guess my question still stands though --
do the differences mean the branch is not vulnerable, or do we need something
different to fix 1.1.4?

The attached patch looks good for the trunk.

Comment 6

[Daniel Veditz [:dveditz]]

The aviary/1.7 branches (zlib 1.1.4) handle the testcases fine.

Comment 7

[Chase Phillips]

Comment on attachment 188021 [details]
explanation and proposed patch

Per 1.1a2 meeting, dveditz granted sr on this patch for trunk landing. 
Granting approval for it to land there.

Comment 8

[Benjamin Smedberg]

I checked this patch in on mozilla trunk. I'm going to leave the bug open
because NSS has their own copy of zlib which should be patched.

Comment 9

[chris hofmann]

should the bug go over to wtc for the nss part?

Comment 10

[Wan-Teh Chang]

Comment on attachment 188021 [details]
explanation and proposed patch

I just checked in this patch on the NSS trunk for NSS 3.11.
The zlib in NSS is only used by the NSS command-line utility
signtool.

Comment 11

[Benjamin Smedberg]

ah, ok. fixed on trunk then, going to close but we still need
investigation/decision about the branches.

Comment 12

[Josh Bressers]

This particular issue only affects zlib 1.2.x.  Anything using 1.1.x is fine.

Comment 13

[Benjamin Smedberg]

*** Bug 300072 has been marked as a duplicate of this bug. ***

Comment 14

[Glenn Randers-Pehrson]

Since this bug has been published by Secunia, I think the security-sensitive
flag can be removed. See http://secunia.com/advisories/15949/

Comment 15

[Neil Williams]

A perusal of signtool and zlib shows inflate() and inflateBack() are the only
two external zlib functions that call the offending inflate_table() functon in
inftrees.c. inflate() is called by the following:
    
    gzio.c:gzread()
    uncompr.c:uncompress()
    jarfile.c:JAR_pass_archive_unverified()
    jarfile.c:JAR_extract()

Signtool only calls JAR_extract() and JAR_pass_archive_unverified() and only
when the verify option is set.
    

   

Comment 16

[Glenn Randers-Pehrson]

inflate() is also used via libpng to decode PNG images.

Comment 17

[Glenn Randers-Pehrson]

Never mind, libpng has nothing to do with zlib in NSS, which would be immune to
the vulnerability anyhow if it is still at zlib 1.1.4 or earlier.

Comment 18

[Nelson Bolyard (seldom reads bugmail)]

Adding Neil and myself to cc list

Comment 19

[Christophe Ravel]

Attachment: Fix for NSS_3_3_4_1_BRANCH

Comment 20

[Christophe Ravel]

Comment on attachment 192100 [details] [diff] [review]
Fix for NSS_3_3_4_1_BRANCH

see https://bugzilla.mozilla.org/show_bug.cgi?id=301212

Comment 21

[Julien Pierre]

Comment on attachment 192100 [details] [diff] [review]
Fix for NSS_3_3_4_1_BRANCH

Canceling reviews on wrong product.