143853 - Bypassing same-origin via Exception.prototype

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[MURAWAKI Yugo]

The prototype of prototype of DOMException instance is a "persistent"
object and arbitrary web pages can add a property to it. This bug
allows circumventing same origin security policy.



----- a.html -----

try {
    document.documentElement.removeChild({}); // causes a DOMException
} catch (e) {
    e.__proto__.__proto__.sd = "secret";
}


----- b.html -----

try {
    document.documentElement.appendChild({}); // causes a DOMException too
} catch (e) {
    alert(e.__proto__.__proto__.sd); // "secret"
}

Comment 1

[Bradley Baetz (:bbaetz)]

confirming, and -> security group.

Testing on RC2 with http://localhost/~bbaetz/foo/a.html and
http://192.168.0.2/~bbaetz/foo/b.html

Is this exploitable? Its a security bug, in any event, though.

Comment 2

[MURAWAKI Yugo]

I think this is exploitable. This is essentially same with an old 
Communicator's bug:
http://packetstormsecurity.nl/9911-exploits/netscape.4.x.java.txt

Comment 3

[John Bandhauer]

e.__proto__.__proto__ == window.Object.prototype as calculated by
XPCWrappedNativeScope::SetGlobal.

e.__proto__ == an instance of XPC_WN_ModsAllowed_Proto_JSClass created by
XPCWrappedNativeProto::Init.

btw jst: The reason you could not do alert(e.__proto__) is because
XPC_WN_Shared_Proto_Convert is broken. It should at least handle the
JSTYPE_STRING case.

Anyway, I notice that this bug does not bite if the documents are openned in
different windows. It looks like the problem is in how xpconnect deals with the
DOM's calls to it that re-init xpconnect's info about the global object.

nsJSContext::InitContext calls nsXPConnect::InitClasses which calls
XPCWrappedNativeScope::GetNewOrUsed which finds an existing
XPCWrappedNativeScope object which has already cached window.Object.prototype
(which is now stale).

I think that XPCWrappedNativeScope::GetNewOrUsed needs to call
XPCWrappedNativeScope::SetGlobal whenever it is called and discovers an existing
XPCWrappedNativeScope for the given global object. This will force it to reload
its cache of the Object.prototype.

I'll give this a try and post a patch if it seems to works right.

Comment 4

[John Bandhauer]

Attachment: proposed fix

This patch looks to be doing the right thing. It fixes the test case for me. I
traced in the debugger and noted that I saw this new code getting called only
on document loads into windows that previously had documents. So, no unexpected
excessive calls that I could see. And, the mPrototypeJSObject really is getting
replaced with a new value as expected. I have not run extensively with the
patch to uncover any other possible problems. Please help test.

Comment 5

[David Bradley]

Comment on attachment 83478 [details] [diff] [review]
proposed fix

r=dbradley

Comment 6

[Johnny Stenback (:jst)]

Comment on attachment 83478 [details] [diff] [review]
proposed fix

sr=jst

Comment 7

[Johnny Stenback (:jst)]

I would think we'd want this for mozilla1.0/MachV, nominating. Jband, feel free
to take this bug from me if you want to roll this in, if not I'll be happy to
push your patch in...

Comment 8

[Johnny Stenback (:jst)]

Fix checked in on the trunk.

Comment 9

[Dawn Endico]

Comment on attachment 83478 [details] [diff] [review]
proposed fix

a=chofmann,brendan,shaver

Comment 10

[scottputterman]

adding adt1.0.0+.  Please checkin to the 1.0 branch.

Comment 11

[Johnny Stenback (:jst)]

Fixed on branch.

Comment 12

[Prashant Desale]

verified1.0.0 on 05-22-18-1.0.0 & also Verified on trunk on 05-23-08-trunk.