Last Comment Bug 698772 - content called by chrome observer can access privileged components
: content called by chrome observer can access privileged components
[sg:critical][qa!] fixed by 705651
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on: CVE-2012-0446
  Show dependency treegraph
Reported: 2011-11-01 09:36 PDT by Bobby Holley (busy)
Modified: 2012-03-30 14:11 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

early testcase (involves SpecialPowers) (3.16 KB, text/plain)
2011-11-01 09:36 PDT, Bobby Holley (busy)
no flags Details
Full Testcase. v1 (6.00 KB, patch)
2011-11-03 10:05 PDT, Bobby Holley (busy)
no flags Details | Diff | Review

Description Bobby Holley (busy) 2011-11-01 09:36:52 PDT
Created attachment 571038 [details]
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:

Which is the result of mSecurityManagerFlags being 0 here:

Which is probably the result of SetSecurityManagerForJSContext not being called for chrome JS contexts:

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 (busy) 2011-11-02 14:08:20 PDT
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 (busy) 2011-11-03 10:05:19 PDT
Created attachment 571683 [details] [diff] [review]
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] 2011-11-16 16:56:36 PST
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 2011-11-28 06:38:15 PST
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 (busy) 2012-01-03 12:30:53 PST
I've done my part here. Reassigning.
Comment 6 Daniel Veditz [:dveditz] 2012-01-11 18:28:19 PST
Bobby: is there more to do here, or was the only known exploitable bit fixed in bug 705651?
Comment 7 Bobby Holley (busy) 2012-01-11 18:47:43 PST
(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 2012-01-12 11:45:37 PST
I think the security problem was fixed by bug 705651.
Comment 9 Jason Smith [:jsmith] 2012-03-13 14:41:33 PDT
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 (busy) 2012-03-13 15:56:15 PDT
(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] 2012-03-13 17:13:07 PDT
Verified as a result of verifying bug 705651.

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