Closed Bug 190996 Opened 22 years ago Closed 22 years ago

potential big libjar leak when file corrupted in archive

Categories

(Core :: Networking, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: dveditz, Assigned: dveditz)

References

()

Details

(Keywords: memory-leak, Whiteboard: [sg:dos])

Attachments

(2 files, 1 obsolete file)

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
Flags: blocking1.3b+
Attached patch plug the leak (obsolete) — Splinter Review
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+
ccing mcarlson
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
Closed: 22 years ago
Resolution: --- → FIXED
Attached file 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
Attachment #112894 - Flags: approval1.0.x?
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).
Group: security
Whiteboard: [sg:dos]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: