Closed
Bug 190996
Opened 22 years ago
Closed 22 years ago
potential big libjar leak when file corrupted in archive
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
VERIFIED
FIXED
People
(Reporter: dveditz, Assigned: dveditz)
References
()
Details
(Keywords: memory-leak, Whiteboard: [sg:dos])
Attachments
(2 files, 1 obsolete file)
2.18 KB,
patch
|
Details | Diff | Splinter Review | |
245 bytes,
application/octet-stream
|
Details |
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 2•22 years ago
|
||
Assignee | ||
Comment 3•22 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?
Attachment #112894 -
Flags: review?(ssu) → review+
Comment 4•22 years ago
|
||
ccing mcarlson
Assignee | ||
Comment 5•22 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•22 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•22 years ago
|
||
Assignee | ||
Comment 9•22 years ago
|
||
Fix checked in to trunk and Netscape branch, but not the 1.0 branch.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•22 years ago
|
||
Attachment #112894 -
Attachment is obsolete: true
Assignee | ||
Comment 11•22 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•22 years ago
|
Attachment #113234 -
Flags: approval1.0.x+
Assignee | ||
Comment 12•22 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•22 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•20 years ago
|
||
Comment on attachment 112894 [details] [diff] [review] plug the leak branch dead
Attachment #112894 -
Flags: approval1.0.x?
Assignee | ||
Comment 15•20 years ago
|
||
Comment on attachment 113234 [details] [diff] [review] incorporate Heikki's suggestions branch dead
Attachment #113234 -
Flags: approval1.0.x?
Comment 16•20 years ago
|
||
since this is long fixed, and was only a memleak, not a security exploit, can it be opened?
Assignee | ||
Comment 17•20 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.
Description
•