Bug 705651 (CVE-2012-0446)

Frame scripts that access untrusted objects are exploitable

VERIFIED FIXED in Firefox 10

Status

()

Core
Security
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: moz_bug_r_a4, Assigned: smaug)

Tracking

({verified-beta})

unspecified
mozilla11
x86
Windows XP
verified-beta
Points:
---
Bug Flags:
sec-review +

Firefox Tracking Flags

(firefox8 wontfix, firefox9 wontfix, firefox10+ verified, firefox11+ verified, firefox-esr10 unaffected, status1.9.2 unaffected)

Details

(Whiteboard: [sg:critical][qa!][secr:dveditz])

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
Frame scripts run on the special JS context for which we call SetSecurityManagerForJSContext with flags=0, thus if a frame script calls into an untrusted function, XPConnect does not do proper security checks.
(Reporter)

Comment 4

6 years ago
Created attachment 577241 [details]
screenshot of testcase 3
Nice :(

mrbkap, what kinds of flags can be passed to SetSecurityManagerForJSContext?
There is no documentation in nsIXPConnect nor in nsXPConnect.cpp
Assignee: nobody → bugs
I'm pretty sure 0 is passed because it is (or was) passed also here
http://mxr.mozilla.org/mozilla2.0/source/dom/src/threads/nsDOMThreadService.cpp#1075
Ahaa, some documentation is here
http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/idl/nsIXPCSecurityManager.idl#61
Should I pass HOOK_ALL ?
Hey Olli. I don't think you actually need to call SetSecurityManagerForJSContext at all. That function is useful if a given context needs to use a different security manager from the rest of the runtime. However, in most cases, we can just use the one that's installed on XPConnect itself. On the other hand, using HOOK_ALL would also fix this bug.
Created attachment 577535 [details] [diff] [review]
patch

Create a helper method.
Attachment #577535 - Flags: review?(mrbkap)
Comment on attachment 577535 [details] [diff] [review]
patch

Review of attachment 577535 [details] [diff] [review]:
-----------------------------------------------------------------

I mentioned on IRC that the reason that web workers got away with this (before the recent rewrite) is that they truly used object capabilities to protect themselves. Furthermore, they couldn't use the script security manager off the main thread, and therefore wanted to *prevent* calls to the SSM. Because there was nothing around to protect, this was safe.

::: content/base/src/nsFrameMessageManager.cpp
@@ +840,5 @@
> +
> +  JSAutoRequest ar(cx);
> +  nsIXPConnect* xpc = nsContentUtils::XPConnect();
> +  const PRUint32 flags = nsIXPConnect::INIT_JS_STANDARD_CLASSES |
> +                         /*nsIXPConnect::OMIT_COMPONENTS_OBJECT ?  |*/

I doubt you want this flag. It's only useful if you want to cut the scripts you're going to be running off from XPCOM entirely.

Updated

6 years ago
Attachment #577535 - Flags: review?(mrbkap) → review+
Yeah, that flag has been there since the beginning when it wasn't sure whether we want to
expose components to frame scripts or let them do only simpler things.
I'll remove that.
Created attachment 577960 [details] [diff] [review]
up-to-date
https://hg.mozilla.org/mozilla-central/rev/5ce8d4e02e81
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
I'll prepare patches for aurora and beta.
tracking-firefox10: --- → ?
tracking-firefox9: --- → ?
Created attachment 578220 [details] [diff] [review]
for aurora

The only difference to trunk is that trunk doesn't have
| JSOPTION_JIT
Attachment #578220 - Flags: approval-mozilla-aurora?
Attachment #578220 - Attachment description: for aurota → for aurora
In beta there is also JS_SetScriptStackQuota and  JSOPTION_ANONFUNFIX |
Now tracking for FF9/10, and added the sec-review-needed keyword. Please address possible risk for taking on aurora/beta.
tracking-firefox10: ? → +
tracking-firefox8: --- → +
tracking-firefox9: ? → +
Keywords: sec-review-needed
Whiteboard: [qa+]
There is little risk here, we should take this for aurora (fx10)
Keywords: sec-review-needed → sec-review-complete
Whiteboard: [qa+] → [sg:critical][qa+][secr:dveditz]
little risk from the patch, I mean! It's a bad security hole that's probably exploitable through several addons and definitely exploitable through an XSS on AMO.

Updated

6 years ago
Attachment #578220 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/677dfd331c5b
status-firefox10: --- → fixed

Updated

6 years ago
status-firefox11: --- → fixed
status-firefox8: --- → wontfix
status-firefox9: --- → wontfix
tracking-firefox11: --- → +
Target Milestone: --- → mozilla11
status1.9.2: --- → unaffected
Alias: CVE-2012-0446
Blocks: 698772
Verified fixed in Firefox 11.0b6.
status-firefox11: fixed → verified
Keywords: verified-beta
Verified fixed in Firefox Aurora.
Verified fixed in Firefox Nightly.
Status: RESOLVED → VERIFIED

Updated

5 years ago
status-firefox10: fixed → verified
Whiteboard: [sg:critical][qa+][secr:dveditz] → [sg:critical][qa!][secr:dveditz]
status-firefox-esr10: --- → unaffected
tracking-firefox8: + → ---
tracking-firefox9: + → ---
Group: core-security
Flags: sec-review+
You need to log in before you can comment on or make changes to this bug.