190996 - potential big libjar leak when file corrupted in archive

Status: VERIFIED FIXED

Description

[Daniel Veditz [:dveditz]]

In nsZipArchive::ReadInit the buffer is not freed if there's an error
decompressing, leading to a file-sized memory leak. This is used by jar:
protocol URLs. This is not likely or common in normal use since most jar:
protocol use is to our own heavily QA'd chrome which is then CRC checked at
install time. But we could run across an external jar: URL and corrupt the file
on download. 

This probably could be used as a nasty DOS attack so I'm marking this security
sensitive.

Comment 1

[Daniel Veditz [:dveditz]]

Should get fixed in 1.3b

Comment 2

[Daniel Veditz [:dveditz]]

Created attachment 112894 [details] [diff] [review]
plug the leak

Comment 3

[Daniel Veditz [:dveditz]]

Comment on attachment 112894 [details] [diff] [review]
plug the leak

Should land on trunk and probably 1.0 branch

Comment 4

[Michael Buckland]

ccing mcarlson

Comment 5

[Daniel Veditz [:dveditz]]

ns approval=rebron in person, still need drivers a=

Comment 6

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 112894 [details] [diff] [review]
plug the leak

sr=heikki

Do you need to do PR_FREEIF, or is there PR_FREE (as we should know by now the
allocation was succesfull)?

You could make it so that we check item->compression first, before allocating,
so it would be more robust in a case like this. Your call if you want to make
it so.

Comment 7

[Asa Dotzler [:asa]]

Comment on attachment 112894 [details] [diff] [review]
plug the leak

a=asa (on behalf of drivers) for checkin to 1.3beta.

Comment 8

[Daniel Veditz [:dveditz]]

Created attachment 113234 [details] [diff] [review]
incorporate Heikki's suggestions

Comment 9

[Daniel Veditz [:dveditz]]

Fix checked in to trunk and Netscape branch, but not the 1.0 branch.

Comment 10

[Daniel Veditz [:dveditz]]

Created attachment 113243 [details]
corrupt archive

Comment 11

[Daniel Veditz [:dveditz]]

To demonstrate the leak open the URL
jar:http://bugzilla.mozilla.org/attachment.cgi?id=113243!/zen2.txt

The archive itself is tiny but each time Mozilla opens a link to it we leak 16Mb
(arbitrary value I encoded into the archive so leak would be easy to see when
testing).

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 113234 [details] [diff] [review]
incorporate Heikki's suggestions

sorry, meant to request 1.0.x approval, not grant it

Comment 13

[bmartin]

Marking this Verified Fixed

Testing against Branch 2002-02-10-09 on Win2000.

1. Run Windows Task Manager to view the Netscp.exe process running in the
Processes Tab.
2. Go to: jar:http://bugzilla.mozilla.org/attachment.cgi?id=113243!/zen2.txt and
then Shift+Reload this a few times to see if the Memory Usage increases by 16MB.

Results:
The 16MB leak doesn't occur as it did in previous versions.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 112894 [details] [diff] [review]
plug the leak

branch dead

Comment 15

[Daniel Veditz [:dveditz]]

Comment on attachment 113234 [details] [diff] [review]
incorporate Heikki's suggestions

branch dead

Comment 16

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

since this is long fixed, and was only a memleak, not a security exploit, can it
be opened?

Comment 17

[Daniel Veditz [:dveditz]]

Sorry, yes, this should have been opened. It was more than "only" a memleak, it
was quite easy to DOS someone by gobbling all their memory. Of course the same
can be done with large images (see various bugs on that).