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.
Should get fixed in 1.3b
Comment on attachment 112894 [details] [diff] [review] plug the leak Should land on trunk and probably 1.0 branch
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 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+
Fix checked in to trunk and Netscape branch, but not the 1.0 branch.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Created attachment 113243 [details] corrupt archive
Attachment #112894 - Attachment is obsolete: true
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).
Attachment #113234 - Flags: approval1.0.x+
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?
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
Comment on attachment 112894 [details] [diff] [review] plug the leak branch dead
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?
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).
You need to log in before you can comment on or make changes to this bug.