Closed
Bug 330818
Opened 18 years ago
Closed 18 years ago
memory corruption involving boxObject.
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: guninski, Assigned: neil)
References
Details
(Keywords: fixed1.8.1, testcase, verified1.8.0.4, Whiteboard: [sg:critical?] uses freed objects)
Attachments
(3 files, 2 obsolete files)
77 bytes,
text/html
|
Details | |
861 bytes,
text/html
|
Details | |
698 bytes,
patch
|
jst
:
approval-branch-1.8.1+
dveditz
:
approval1.8.0.4+
|
Details | Diff | Splinter Review |
memory corruption involving boxObject. conside iframe i1 in iframe f1. bo=i1.boxObject set the location of f1 to "about:blank", probably destroying a lot of i1, including bo. enumerate bo and crash with $eip depending on previous actions. in some cases abort() because of "pure virtual method". vulnerable: ff 1.5latest and trunk, seamonkey trunk.
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Comment 2•18 years ago
|
||
Reporter | ||
Comment 3•18 years ago
|
||
Bug 328839 is similar
Assignee | ||
Comment 4•18 years ago
|
||
My trunk build crashes in nsBoxObject::GetElement where mContent has an incomplete virtual table (it points to __vt_7nsINode).
Assignee | ||
Comment 5•18 years ago
|
||
This is a 1-line fix. We just need to check that document.getBoxObjectFor is getting a box object for an element in that document.
Assignee | ||
Comment 6•18 years ago
|
||
Which error code? document.getBoxObjectFor(null) throws NS_ERROR_UNEXPECTED; document.createElement("box").boxObject throws NS_ERROR_FAILURE.
Assignee: nobody → neil
Status: NEW → ASSIGNED
Attachment #215439 -
Flags: superreview?(jst)
Attachment #215439 -
Flags: review?(jst)
Comment 7•18 years ago
|
||
Comment on attachment 215439 [details] [diff] [review] Proposed patch How about NS_ERROR_DOM_WRONG_DOCUMENT_ERR? r+sr=jst
Attachment #215439 -
Flags: superreview?(jst)
Attachment #215439 -
Flags: superreview+
Attachment #215439 -
Flags: review?(jst)
Attachment #215439 -
Flags: review+
Comment 8•18 years ago
|
||
Affects 1.0.x as well.
Flags: blocking1.8.0.3+
Flags: blocking-firefox2+
Flags: blocking-aviary1.0.9+
Whiteboard: [sg:critical?] uses freed objects
Updated•18 years ago
|
Attachment #215439 -
Flags: approval1.8.0.3?
Attachment #215439 -
Flags: approval-branch-1.8.1?
Attachment #215439 -
Flags: approval-aviary1.0.9?
Assignee | ||
Comment 9•18 years ago
|
||
Attachment #215485 -
Flags: approval1.8.0.3?
Attachment #215485 -
Flags: approval-branch-1.8.1?(jst)
Assignee | ||
Comment 10•18 years ago
|
||
Attaching the right file this time ;-)
Attachment #215439 -
Attachment is obsolete: true
Attachment #215485 -
Attachment is obsolete: true
Attachment #215486 -
Flags: approval1.8.0.3?
Attachment #215486 -
Flags: approval-branch-1.8.1?(jst)
Attachment #215439 -
Flags: approval1.8.0.3?
Attachment #215439 -
Flags: approval-branch-1.8.1?
Attachment #215439 -
Flags: approval-aviary1.0.9?
Attachment #215485 -
Flags: approval1.8.0.3?
Attachment #215485 -
Flags: approval-branch-1.8.1?(jst)
Assignee | ||
Comment 11•18 years ago
|
||
Fix checked in to the trunk. The patch applies to the 1.8 and 1.0.8 branches but neither of the 1.7 branches; I can try to run up a suitable patch but I won't be able to test it.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Flags: review+
Flags: blocking-firefox2+
Product: Firefox → Core
Resolution: --- → FIXED
Updated•18 years ago
|
Attachment #215486 -
Flags: approval-branch-1.8.1?(jst) → approval-branch-1.8.1+
Reporter | ||
Comment 13•18 years ago
|
||
+ NS_ENSURE_TRUE(content->GetCurrentDoc() == this, + NS_ERROR_DOM_WRONG_DOCUMENT_ERR); while this stops the current crash, does it stop the following: the inner frames gets the boxObject and pass it to the parent window (works, but no crash). mean - is it safe or just my testcase is not l33t enough?
Assignee | ||
Comment 14•18 years ago
|
||
(In reply to comment #13) >+ NS_ENSURE_TRUE(content->GetCurrentDoc() == this, >+ NS_ERROR_DOM_WRONG_DOCUMENT_ERR); > >while this stops the current crash, does it stop the following: > >the inner frames gets the boxObject and pass it to the parent window (works, but no crash). > >mean - is it safe or just my testcase is not l33t enough? Getting the box object from the correct document should already be safe.
Reporter | ||
Comment 15•18 years ago
|
||
(In reply to comment #14) > Getting the box object from the correct document should already be safe. > was the problem ref counting related?
Assignee | ||
Comment 16•18 years ago
|
||
(In reply to comment #15) >was the problem ref counting related? Not directly. The box object's reference is cleared by the element's document. You had bypassed that by getting a box object using an unrelated document.
Reporter | ||
Comment 17•18 years ago
|
||
(In reply to comment #16) > Not directly. The box object's reference is cleared by the element's document. > You had bypassed that by getting a box object using an unrelated document. are there known other objects that are cleared by a document and can be accessed from unrelated documents?
Assignee | ||
Comment 18•18 years ago
|
||
(In reply to comment #17) >are there known other objects that are cleared by a document and can be >accessed from unrelated documents? I hope not! This one just happened to be in an area of code that I knew about.
Comment 19•18 years ago
|
||
Comment on attachment 215486 [details] [diff] [review] Updated for check in approved for 1.8.0 branch, a=dveditz for drivers
Attachment #215486 -
Flags: approval1.8.0.3? → approval1.8.0.3+
Comment 21•18 years ago
|
||
v.fixed on 1.8.0 branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060420 Firefox/1.5.0.2, no crash with testcase.
Updated•18 years ago
|
Flags: blocking1.7.14?
Comment 22•18 years ago
|
||
possible fallout in https://bugzilla.mozilla.org/show_bug.cgi?id=340084 ?
Reporter | ||
Comment 23•18 years ago
|
||
can't see the other bug, so can't comment.
Updated•18 years ago
|
Group: security
You need to log in
before you can comment on or make changes to this bug.
Description
•