Talk:XPCNativeWrapper: Difference between revisions

From MozillaZine Knowledge Base
Jump to navigationJump to search
(re em_te)
(re asqueella)
Line 24: Line 24:


::[[User:Asqueella|asqueella]]
::[[User:Asqueella|asqueella]]
:::Thanks for the clarifications. There were so many misunderstandings I didn't know I had. I've updated the examples to reflect the stricter requirement for exploitation for Pre-1.1 for now and will update it again when 1.1 is out. I don't have 1.1 yet so I haven't tested the code for that. If the <code>setter=eval</code> is fixed in 1.1 then this article can be deleted.
:::P.S. Your link to bug 217195#c15 links to bug 223041 which is marked private which I cannot read.
:::-Emte

Revision as of 00:11, 23 March 2005

You scared me with "Attack Scenarios" paragraph, because *a lot* of extensions access _content.document's properties without this wrapper. However, when I tried to access Components.classes in document.title setter and accessed that from Extension Developer's Extension's JS Shell (chrome priviledges) it (fortunately) failed with permission denied error.

I see however, that code in Firefox uses XPCNativeWrapper when accessing page's document.

Can someone explain me it / give a working attack page, because if we should really use XPCNativeWrapper, then almost everybody using extensions is vulnerable.

asqueella 04:13, 22 Mar 2005 (PST)

There are two bugs related to this attack on Jesse Ruderman's Security Page:
-Emte
Thanks for the pointers.
The thing is, it's not as easy as you pictured it. Just accessing the properties (or even calling methods!) doesn't execute malcious code with elevated priviledges. You need to eval() (or equivalent, like setting document.location) a string from script to be compromised.
The trick with setting setter=eval is fixed for at least Firefox 1.1 (maybe earlier, the bug is still closed), as I understand it (see [1]), so it's not easy to write a security hole anymore (while still possible of course).
What's true is that the code from the page may throw an exception and if you don't catch it, you've got a problem.
Summary: I think attack scenarios section should be updated.
asqueella
Thanks for the clarifications. There were so many misunderstandings I didn't know I had. I've updated the examples to reflect the stricter requirement for exploitation for Pre-1.1 for now and will update it again when 1.1 is out. I don't have 1.1 yet so I haven't tested the code for that. If the setter=eval is fixed in 1.1 then this article can be deleted.
P.S. Your link to bug 217195#c15 links to bug 223041 which is marked private which I cannot read.
-Emte