Closed
Bug 132657
Opened 22 years ago
Closed 22 years ago
International chars in <IMG SRC=...> leads to crash
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
RESOLVED
DUPLICATE
of bug 138877
mozilla1.0
People
(Reporter: security-bugs, Assigned: dougt)
Details
Attachments
(3 files)
356 bytes,
text/plain
|
Details | |
314 bytes,
text/plain
|
Details | |
1.13 KB,
patch
|
Details | Diff | Splinter Review |
There is a problem with <img src="...international chars...">. Some memory gets badly overwritten, may be exploitable. Yesterday's nightly crashed in an exploitable way - it ended in user-specified memory. Today's nightly crashed in free() which is more difficult to exploit. Seems like someone has committed changes. How to reproduce: imgchars.pl is a perl cgi. Access it, expected result is crash. If it does not crash, click on the submit button (points to non-existent url) the click 'back' from the toolbar.
Reporter | ||
Comment 1•22 years ago
|
||
Reporter | ||
Updated•22 years ago
|
Comment 2•22 years ago
|
||
This is similar to bug 128825 http://bugzilla.mozilla.org/show_bug.cgi?id=128825 which is claimed to be fixed but this bug still remains. I am almost sure this is exploitable the only difficulty being the return address must be unicode.
Comment 3•22 years ago
|
||
Mitch, we're pushing RC1 today (builds 2002041711). Are we likely to get this in time for RC2 (about 2 weeks) or 1.0 final (about 3 or 4 weeks, hopefully)?
Reporter | ||
Comment 4•22 years ago
|
||
dougt has agreed to take this (thanks Doug!) Here's what I've found so far: The crash appears to be heap corruption, since the call stack at crash time varies on each run but is always in a malloc or free operation. For the crash to occur, the first character of the path portion of the IMG SRC url must have a value greater than 128, and it must be followed by at least 15-20 more chars of any value.
Reporter | ||
Comment 6•22 years ago
|
||
Here's a simpler testase. If you're inside Netscape's firewall, it's also at http://grey/cgi-bin/bo2b.pl
Assignee | ||
Comment 7•22 years ago
|
||
Basically, we are trusting the content type of the page as the correct key into our url segment parsing code, which of course is wrong. The fix is clean and small.
Assignee | ||
Comment 8•22 years ago
|
||
Since the charset of the spec is known, we hard code it. I am not sure if I should being a NS_LITERAL_CSTRING? This does not optimize callers to do the right thing. For example the source of the problem could remove the charset parameter and pass null. In fact every caller of NS_NewURI using a astring could ignore the charset flag: http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsImageFrame.cpp#2030 and I am somewhat worried about this code (did it every work?): http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDefaultURIFixup.cpp#121 Darin can you verify that this is the correct thing to do, or give an example why we would pass a UTF-8 spec in and lie about the charset?
Assignee | ||
Comment 9•22 years ago
|
||
darin says this is a dup which was fixed *** This bug has been marked as a duplicate of 138877 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reporter | ||
Updated•22 years ago
|
Group: security?
You need to log in
before you can comment on or make changes to this bug.
Description
•