698772 - content called by chrome observer can access privileged components

Status: VERIFIED FIXED

(Core :: XPConnect, defect)

Description

[Bobby Holley (:bholley)]

Attachment: early testcase (involves SpecialPowers)

I was removing a bunch of enablePrivilege removal today, and I came across an interesting test case: a content function, registered as an XPCOM observer, can do scary things _without_ the call to enablePrivilege.

khuey and I spent some time digging into the issue.

It seems like sm is NULL here: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSID.cpp#737

Which is the result of mSecurityManagerFlags being 0 here: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/xpcprivate.h#919

Which is probably the result of SetSecurityManagerForJSContext not being called for chrome JS contexts: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/nsXPConnect.cpp#1738

When things started to seems scary, we switched to PM and made some phony comments on #developers about everything being ok. ;-)

In theory, we probably shouldn't be registering content functions as XPCOM observers. But the scary bit here is that this works even if the observer function is chrome, so long as it calls into content.

The testcase I have right now is unfortunately wound up in SpecialPowers stuff, but it otherwise works. Change the file path appropriately, and running the test should dump files onto your desktop.

khuey is going to poke at the test case over the next few hours and see if he can reduce it a bit, hopefully to something not involving SpecialPowers.

mrbkap - can you weight on on the overall security model for this stuff? Is this dangerous?

Comment 1

[Bobby Holley (:bholley)]

I spent a good part of today digging into this a bit more, and still haven't gotten to the bottom of it. It seems like the privileges of the observer callback depend on the context in which it was added. If it was added by enablePrivilege('UniversalXPConnect') code, the callback has the proper restricted privileges. If it was added by System Principal code, the callback has expanded privileges.

I'll hopefully get to the bottom of it tomorrow.

Comment 2

[Bobby Holley (:bholley)]

Attachment: Full Testcase. v1

So, I've spent a lot more time digging into this trying to reduce the testcase, and it's been kind of driving me nuts. Every time I remove something seemingly-unrelated to the issue at hand, the problem goes away. ;-)

There are two interesting requirements to trigger the bug:

1 - The _registration_ of the observer must occur through SpecialPowers.addObserver(). Placing the same code that exists in SpecialPowers in the parent XUL document doesn't work.
2 - The observer notification needs to come from necko. Firing the observer notification in the XUL document doesn't work.

I've put together a comprehensive test case that exercises both of the above cases. Attaching.

Comment 3

[Daniel Veditz [:dveditz]]

It's not clear to me if this is a wrapper problem or not. If it is I can see other add-ons trying to similarly pass objects to chrome-privileged functions and maybe getting into trouble.

Is the fact that it's an observer crucial?

Maybe moz_bug_r_a4 can find a more practical abuse of this against something built-in or a popular add-on. If it's just "SpecialPowers" we probably don't care much.

Comment 4

[moz_bug_r_a4]

When the notification comes from necko, there is no JS context on the stack, thus we use the JS context associated with the observer's scope.  The content objects are wrapped in security wrappers, thus the observer A runs on the JS context associated with the global object of the SpecialPowers frame script, and the observer B runs on the JS context associated with the XUL document's window.

When a content function is running on the special JS context for frame scripts, XPConnect does not do proper security checks.  Please see bug 705651.

Comment 5

[Bobby Holley (:bholley)]

I've done my part here. Reassigning.

Comment 6

[Daniel Veditz [:dveditz]]

Bobby: is there more to do here, or was the only known exploitable bit fixed in bug 705651?

Comment 7

[Bobby Holley (:bholley)]

(In reply to Daniel Veditz from comment #6)
> Bobby: is there more to do here, or was the only known exploitable bit fixed
> in bug 705651?

I think moz_bug_r_a4 can better answer that question.

This bug is entirely based around the attached testcase. So assuming that bug 705651 fixes the testcase here, there's nothing left that I know of.

moz_bug_r_a4, can you confirm?

Comment 8

[moz_bug_r_a4]

I think the security problem was fixed by bug 705651.

Comment 9

[Jason Smith [:jsmith]]

Confused on how to verify this bug. Is there an end-user customer test case we could use to simulate the behavior specified in this bug?

Comment 10

[Bobby Holley (:bholley)]

(In reply to Jason Smith from comment #9)
> Confused on how to verify this bug. Is there an end-user customer test case
> we could use to simulate the behavior specified in this bug?

See bug 705651.

Comment 11

[Jason Smith [:jsmith]]

Verified as a result of verifying bug 705651.