User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050702 Firefox/1.0+ Content can make chrome access content-defined object even though XPCNativeWrapper auto-wrapping is enabled. In content window: <a id="a" href="test">a</a> <b id="b">b</b> <script> Object.prototype.href = { }; </script> Then, in chrome JS: content.document.getElementById("a").href is not affected. content.document.getElementById("b").href is the content-defined object. Bug 298892 comment 20 or Bug 299518 can be combined with this bug to execute arbitrary code. Reproducible: Always Steps to Reproduce:

I've confirmed that this works on: Firefox/1.0+ 2005-07-02-07-trunk This is using Node spoofing (Bug 298892 comment 20).

I've confirmed that this works on: Firefox/1.0+ 2005-07-02-07-trunk This is using XPCOM interface spoofing (Bug 299518).

Comment on attachment 188087 [details] Bypassing XPCNativeWrapper with Node spoofing With this test case in DP1.1a1, I get the sidebar opened, but it can't get the stack: Error: uncaught exception: Permission denied to get property UnnamedClass.stack

(In reply to comment #3) > (From update of attachment 188087 [details] [edit]) > With this test case in DP1.1a1, I get the sidebar opened, but it can't get the > stack: > > Error: uncaught exception: Permission denied to get property UnnamedClass.stack > Bug 221490 is related to this error. And other bugs are related to the reason that attachment 188088 [details] doesn't work on DP1.1a1. Please test with the new testcases that should work on both 2005-07-03-06 and DP1.1a1.

This works on both Deer Park a1 and Firefox/1.0+ 2005-07-03-06.

This works on both Deer Park a1 and Firefox/1.0+ 2005-07-03-06.

I thought the trunk's split wrappers would prevent this. Does wrapping only apply to native/script properties of the object itself and not if we walk the prototype chain? These testcases don't work on the aviary branch.

Yeah, wrapping just wraps up the actual object. And the proto chain goes through the content protos; I bet the same exploit could be performed with XPCNativeWrapper.prototype.... The problem is that we really don't want chrome objects as prototypes of the XPCNativeWrapper. Perhaps XPCNativeWrapper prototypes should actually be forced to null explicitly?

Comment on attachment 188363 [details] [diff] [review] Proposed patch (thanks to shaver for advice!) r=jst

Comment on attachment 188363 [details] [diff] [review] Proposed patch (thanks to shaver for advice!) Thanks for fixing this, the GetOrSet wn/wn_obj was my fault. sr+a=me. /be

Fixed for 1.8b3