330818 - memory corruption involving boxObject.

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[georgi - hopefully not receiving bugspam]

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.

Comment 1

[georgi - hopefully not receiving bugspam]

Attachment: inner iframe

Comment 2

[georgi - hopefully not receiving bugspam]

Attachment: potential exploit

Comment 3

[georgi - hopefully not receiving bugspam]

Bug 328839 is similar

Comment 4

[[e-mail]]

My trunk build crashes in nsBoxObject::GetElement where mContent has an incomplete virtual table (it points to __vt_7nsINode).

Comment 5

[[e-mail]]

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.

Comment 6

[[e-mail]]

Attachment: Proposed patch

Which error code? document.getBoxObjectFor(null) throws NS_ERROR_UNEXPECTED; document.createElement("box").boxObject throws NS_ERROR_FAILURE.

Comment 7

[Johnny Stenback (:jst)]

Comment on attachment 215439 [details] [diff] [review]
Proposed patch

How about NS_ERROR_DOM_WRONG_DOCUMENT_ERR?

r+sr=jst

Comment 8

[Daniel Veditz [:dveditz]]

Affects 1.0.x as well.

Comment 9

[[e-mail]]

Attachment: Updated for check in

Comment 10

[[e-mail]]

Attachment: Updated for check in

Attaching the right file this time ;-)

Comment 11

[[e-mail]]

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.

Comment 12

[[e-mail]]

Fix checked in to the 1.8 branch.

Comment 13

[georgi - hopefully not receiving bugspam]

+  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?

Comment 14

[[e-mail]]

(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.

Comment 15

[georgi - hopefully not receiving bugspam]

(In reply to comment #14)

> Getting the box object from the correct document should already be safe.
> 

was the problem ref counting related?

Comment 16

[[e-mail]]

(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.

Comment 17

[georgi - hopefully not receiving bugspam]

(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?
 

Comment 18

[[e-mail]]

(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

[Daniel Veditz [:dveditz]]

Comment on attachment 215486 [details] [diff] [review]
Updated for check in

approved for 1.8.0 branch, a=dveditz for drivers

Comment 20

[[e-mail]]

Fix checked in to the 1.8.0 branch.

Comment 21

[Jay Patel [:jay]]

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.

Comment 22

[chris hofmann]

possible fallout in https://bugzilla.mozilla.org/show_bug.cgi?id=340084 ?

Comment 23

[georgi - hopefully not receiving bugspam]

can't see the other bug, so can't comment.