potential big libjar leak when file corrupted in archive

VERIFIED FIXED

Status

()

--
major
VERIFIED FIXED
16 years ago
14 years ago

People

(Reporter: dveditz, Assigned: dveditz)

Tracking

({memory-leak})

Trunk
memory-leak
Points:
---
Bug Flags:
blocking1.3b +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:dos], URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
Should get fixed in 1.3b
Flags: blocking1.3b+
(Assignee)

Comment 2

16 years ago
Created attachment 112894 [details] [diff] [review]
plug the leak
(Assignee)

Comment 3

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

Should land on trunk and probably 1.0 branch
Attachment #112894 - Flags: superreview?(heikki)
Attachment #112894 - Flags: review?(ssu)
Attachment #112894 - Flags: approval1.3b?
Attachment #112894 - Flags: approval1.0.x?

Updated

16 years ago
Attachment #112894 - Flags: review?(ssu) → review+

Comment 4

16 years ago
ccing mcarlson
(Assignee)

Comment 5

16 years ago
ns approval=rebron in person, still need drivers a=
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.
Attachment #112894 - Flags: superreview?(heikki) → superreview+

Comment 7

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

a=asa (on behalf of drivers) for checkin to 1.3beta.
Attachment #112894 - Flags: approval1.3b? → approval1.3b+
(Assignee)

Comment 8

16 years ago
Created attachment 113234 [details] [diff] [review]
incorporate Heikki's suggestions
(Assignee)

Comment 9

16 years ago
Fix checked in to trunk and Netscape branch, but not the 1.0 branch.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

16 years ago
Created attachment 113243 [details]
corrupt archive
Attachment #112894 - Attachment is obsolete: true
(Assignee)

Comment 11

16 years ago
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).
(Assignee)

Updated

16 years ago
Attachment #113234 - Flags: approval1.0.x+
(Assignee)

Comment 12

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

sorry, meant to request 1.0.x approval, not grant it
Attachment #113234 - Flags: approval1.0.x+ → approval1.0.x?

Comment 13

16 years ago
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.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 14

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

branch dead
Attachment #112894 - Flags: approval1.0.x?
(Assignee)

Comment 15

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

branch dead
Attachment #113234 - Flags: approval1.0.x?
since this is long fixed, and was only a memleak, not a security exploit, can it
be opened?
(Assignee)

Comment 17

14 years ago
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).
Group: security
Whiteboard: [sg:dos]
You need to log in before you can comment on or make changes to this bug.