Closed
Bug 319154
Opened 19 years ago
Closed 2 years ago
messing with chrome xbl
Categories
(Core :: General, defect)
Core
General
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: guninski, Unassigned)
References
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051129 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051129 Firefox/1.6a1 it is possible to inject js in chrome xbl via textbox.xml/setTimeout. it is done by redefining _fireCommand on textbox of time "timed". the js seems to get executed with luser's privilege, but when trying to do privileged stuff, the exception in the js console is: JavaScript error: , line 0: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "chrome://global/content/bindings/textbox.xml Line: 190"] this may be a potential problem, but may be also invalid. ----xul---- <textbox type="timed" cols="80" rows="200" name="vvvv" timeout="1000" id="t1"></textbox> <script type="application/x-javascript"> <![CDATA[ function f() { var tb=document.getElementById("t1"); tb._fireCommand="openDialog()"; } setTimeout("f()",1000); ]]> </script> <description flex="1"> Type something into the box and check for exception in the js console. </description> ----xul----- Reproducible: Always
Reporter | ||
Comment 1•19 years ago
|
||
testcase
Reporter | ||
Comment 2•19 years ago
|
||
checking what cookies are accessible from bugzilla.mozilla.org
Reporter | ||
Comment 3•19 years ago
|
||
looks like malicous attachments may access all cookies from b.m.o, which eventually may be potentially used to access restricted bugs. a potential solution is attachments to be served from a useless domain with virtual web server.
Comment 4•19 years ago
|
||
So given that XBL runs with page privileges, we're OK here. If it did not, this binding would need some serious thought; adding blocking of bug 59701. In my opinion this bug should not be security-sensitive so that people working on bug 59701 can see this. If someone feels that the material in comment 2 and comment 3 means that this bug should stay security-sensitive (given that the bugzilla bugs on that issue are, I can see people feeling that way), then we should probably close this bug out and file a new open bug on on the real issue at hand.
Blocks: 59701
Reporter | ||
Comment 5•19 years ago
|
||
question: in content/xbl/src/nsXBLBinding.cpp nsXBLBinding::DoInitJSClass // Make a new object prototyped by parent_proto and parented by global. proto = ::JS_InitClass(cx, // context global, i would like to try to get this "global" object via js. can someone provide a testcase for this (probably involving __parent__) because i couldn't do it.
Comment 6•19 years ago
|
||
That global is the inner of the window object (that is, it's the global object for the document in which the element the binding is being attached to lives). You can just walk the __parent__ chain on the bound node to get to that global.
Comment 7•19 years ago
|
||
(In reply to comment #7) > That global is the inner of the window object (that is, it's the global object > for the document in which the element the binding is being attached to lives). > You can just walk the __parent__ chain on the bound node to get to that global. But the __parent__ getter censors the inner object, returning the outer for it. /be
Reporter | ||
Comment 8•19 years ago
|
||
another question: can someone please tell me the codepath for this: <script> alert(window.QueryInterface(Components.interfaces.nsISupportsWeakReference).GetWeakReference()); </script> QueryInterfaces passes, returning window object, but then something throws a js exception.
Comment 9•19 years ago
|
||
You need UniversalXPConnect permissions to use weak references.
Reporter | ||
Comment 10•19 years ago
|
||
(In reply to comment #10) > You need UniversalXPConnect permissions to use weak references. > i was interested in which methods get invoked by this example.
Updated•19 years ago
|
Whiteboard: [sg:nse]
Comment 11•19 years ago
|
||
is this bug attacking firefox xbl, toolkit xbl, or some gecko core module? if any of the latter, could we please move it?
Reporter | ||
Comment 12•19 years ago
|
||
(In reply to comment #12) > is this bug attacking firefox xbl, toolkit xbl, or some gecko core module? if > any of the latter, could we please move it? > i am not sure it is a real attack, so the bug may be invalid.
Reporter | ||
Comment 13•18 years ago
|
||
tb._fireCommand="var er=new Error();alert('Error.stack='+er.stack)"; gives interesting stack. on 1.5: Error()@0 @chrome://global/... on trunk: Error()@0 @0
Reporter | ||
Comment 14•18 years ago
|
||
Updated•18 years ago
|
Whiteboard: [sg:nse] → [sg:nse] comment 3 reveals bug 38862
Comment 15•17 years ago
|
||
Does anyone object to hiding comments 2 and 3, and then opening this bug, now that we have the ability to hide comments?
Reporter | ||
Comment 16•17 years ago
|
||
(In reply to comment #16) > Does anyone object to hiding comments 2 and 3, and then opening this bug, now > that we have the ability to hide comments? > i don't object. just for the record comment 2 and comment 3 are mine according to bugmail.
Comment 17•17 years ago
|
||
No objection. Gerv
Updated•17 years ago
|
Group: security
OS: Linux → All
Product: Firefox → Core
QA Contact: general → general
Hardware: PC → All
Updated•17 years ago
|
Attachment #205040 -
Attachment is private: true
Updated•16 years ago
|
Whiteboard: [sg:nse] comment 3 reveals bug 38862
Comment 18•2 years ago
|
||
XBL is dead, long live XBL.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•