content called by chrome observer can access privileged components

VERIFIED FIXED

Status

()

Core
XPConnect
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: bholley, Unassigned)

Tracking

unspecified
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox10 verified, firefox11 verified, firefox12 verified, firefox13 verified, firefox-esr10 unaffected, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical][qa!] fixed by 705651)

Attachments

(2 attachments)

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: 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?
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.
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.
Assignee: nobody → bobbyholley+bmo
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

6 years ago
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.
I've done my part here. Reassigning.
Assignee: bobbyholley+bmo → nobody
Bobby: is there more to do here, or was the only known exploitable bit fixed in bug 705651?
(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

5 years ago
I think the security problem was fixed by bug 705651.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
status1.9.2: --- → unaffected
status-firefox-esr10: --- → unaffected
status-firefox10: --- → fixed
status-firefox11: --- → fixed
status-firefox12: --- → fixed
status-firefox13: --- → fixed
Depends on: 705651
Resolution: --- → FIXED
Whiteboard: fixed by 705651
Whiteboard: fixed by 705651 → [qa+] fixed by 705651
Whiteboard: [qa+] fixed by 705651 → [sg:critical][qa+] fixed by 705651
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?
(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.

Updated

5 years ago
status-firefox11: fixed → verified
Verified as a result of verifying bug 705651.
Status: RESOLVED → VERIFIED
status-firefox10: fixed → verified
status-firefox12: fixed → verified
status-firefox13: fixed → verified
Whiteboard: [sg:critical][qa+] fixed by 705651 → [sg:critical][qa!] fixed by 705651
Group: core-security
You need to log in before you can comment on or make changes to this bug.