Bug 783260 (CVE-2012-3991)

Error: Error: Permission denied to access property 'toString' when open certain site

VERIFIED FIXED

Status

()

Core
Security: CAPS
VERIFIED FIXED
5 years ago
11 months ago

People

(Reporter: Alice0775 White, Assigned: bholley)

Tracking

({sec-critical})

16 Branch
x86
Windows 7
sec-critical
Points:
---
Dependency tree / graph
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox15 wontfix, firefox16- verified, firefox17- verified, firefox18- verified, firefox-esr1016+ verified)

Details

(Whiteboard: [sg:critical][advisory-tracking+]security issue fixed by 754202 on m-c)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
This appears in Aurora16.0a2 and Nightly17.0a1.
(The appearance of the page does not seem to have the problem in particular.)


Step To Reproduce:

1. Load http://ww2.noticiasmvs.com/entrevistas/primera-emision-con-carmen-aristegui/postura-de-mvs-sobre-rescate-banda-25-ghz-conferencia-de-prensa-139.html

Actual Results:
  The following error shown in Error Console
  Error: Permission denied to access property 'toString
Bobby, please take a look into this?  There's a good chance NPAPI is involved...
Status: UNCONFIRMED → NEW
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
Ever confirmed: true
Keywords: regression
tracking-firefox16: ? → +
tracking-firefox17: ? → +
Created attachment 652523 [details]
stack

Attaching a stack.
The plugin, which lives in a youtube iframe, appears to be toString()-ing window.location of the cross-origin parent frame, which is being rightfully denied. I'm going to see what's different on beta.
I believe Flash does this on purpose, and bases part of their security policy on it or something....  So if it used to work, it needs to keep working.

How exactly is the plug-in doing this?  Is it just doing a NPN_LoadURI or whatever on a javascript: URI?
Oh, it's doing it via explicit NP_Invoke.  OK.
This is actually an sg:crit on beta. Awesome.
Group: core-security
The call succeeds because the check for UniversalXPConnect returns true. The reason is that nsScriptSecurityManager::IsCapabilityEnabled doesn't find an fp (since there's no script code on the stack), and there's no principal pushed either. So it grants all privileges.
Ironically, this bug was reported because we _fixed_ the security hole here, via bug 754202. For beta and esr, we should probably push a principal somewhere.
So basically, NP_Invoke invokes methods by doing a GetProperty via JSAPI, testing if it's a function, and then invoking it. But because the GetProperty operation isn't scripted, our security wrappers are entirely bypassed when getting cross-origin properties, because they always succeed with the check for UniversalXPConnect. I think pushing a principal in do_Invoke will work, but I'm not sure if there are other callsites that are similarly vulnerable.

Maybe bsmedberg or jst can tell me if there are other analogous situations in the plugin code.
Actually, is it even worth writing a patch against beta? The code freeze already happened, right? Maybe just against ESR10?
This is totally up moz_bug_r_a4's alley.

Comment 12

5 years ago
I think that all of the raw JSAPI usage here is within nsJSNPRuntime.cpp, and I would guess that we would also need to push for any other NPRuntime usage which could be setup by the plugin while content JS is on the stack (which is all NPRuntime usage), so:

hasmethod (maybe?)
invoke
invokeDefault
hasProperty
getProperty
setProperty
removeProperty
enumerate
construct
(In reply to Benjamin Smedberg  [:bsmedberg] [away 27-July until 7-Aug] from comment #12)
> I think that all of the raw JSAPI usage here is within nsJSNPRuntime.cpp,
> and I would guess that we would also need to push for any other NPRuntime
> usage which could be setup by the plugin while content JS is on the stack

Do you mean "while no content JS is on the stack"?
Wait.  Isn't this the plug-in trying to get top.location.toString() or something?  Again, should that be allowed cross-site?  I guess it shouldn't, probably, unless Flash depends on it working.
(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #14)
> Wait.  Isn't this the plug-in trying to get top.location.toString() or
> something?

Yes.

> Again, should that be allowed cross-site?

Not per our current security policy, no.

> I guess it shouldn't, probably, unless Flash depends on it working.

Not sure how we could sanely special-case that, but I'm not a plugin expert.
(In reply to Bobby Holley (:bholley) from comment #15)
> (In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from
> comment #14)
[...]
> > I guess it shouldn't, probably, unless Flash depends on it working.
> 
> Not sure how we could sanely special-case that, but I'm not a plugin expert.

It should *not* be permitted across origins, and never has been, so no special casing needed here. Flash merely wants to know whether it's embedding in the a same origin top window or not, or that's at least my understanding, and throwing an exception at them when they do that check across origins is fine.
Keywords: sec-critical
Blocks: 783957
Can we assign someone to work on this, Johnny?
I believe this only needs to be patched on esr10. I was going to work on it this week but didn't have time. :-(

Basically all that needs to happen is to call nsScriptSecurityManager::{Push,Pop}ContextPrincipal at each of NPJSRuntime callsites listed in comment 12.
Bobby will write the patch for this one, thanks!
Assignee: nobody → bobbyholley+bmo
status-firefox-esr10: --- → affected
status-firefox16: --- → unaffected
status-firefox17: --- → unaffected
tracking-firefox16: + → -
tracking-firefox17: + → -
Whiteboard: [sg:critical]
Created attachment 658789 [details] [diff] [review]
Push some princials on esr10

Prepared a patch for esr10 that fixes the testcases in bug 783957. Flagging mrbkap for review.
Attachment #658789 - Flags: review?(mrbkap)
status-firefox18: --- → unaffected
tracking-firefox-esr10: --- → ?
tracking-firefox18: --- → -
tracking-firefox-esr10: ? → 16+
Comment on attachment 658789 [details] [diff] [review]
Push some princials on esr10

Whew, this is subtle. Good riddance to UniversalXPConnect!
Attachment #658789 - Flags: review?(mrbkap) → review+
Comment on attachment 658789 [details] [diff] [review]
Push some princials on esr10

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: security vulnerabilities
Fix Landed on Version: This patch is esr10-only.
Risk to taking this patch (and alternatives if risky): Low risk 
String or UUID changes made by this patch: None

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Attachment #658789 - Flags: approval-mozilla-esr10?

Updated

5 years ago
Attachment #658789 - Flags: approval-mozilla-esr10? → approval-mozilla-esr10+
https://hg.mozilla.org/releases/mozilla-esr10/rev/ee8351424c56

Verification can be done with the testcase in bug 783957.
status-firefox-esr10: affected → fixed
Keywords: verifyme
I'm resolving this FIXED given that it only affected esr10.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical] → [sg:critical][advisory-tracking+]
status-firefox15: --- → affected
status-firefox15: affected → wontfix
This bug was originally filed as a regression of bug 754202, but that initial symptom is essentially "wontfix" or "invalid" and the bug turned into an unknown security issue that had been fixed as a side-effect of bug 754202. "Depends on" 754202 rather than "blocks" more accurately reflects what actually happened here.

Thanks for reporting this, Alice -- would not have found the lurking security problem otherwise.
No longer blocks: 754202
status-firefox16: unaffected → fixed
status-firefox17: unaffected → fixed
status-firefox18: unaffected → fixed
Depends on: 754202
Keywords: regression
Whiteboard: [sg:critical][advisory-tracking+] → [sg:critical][advisory-tracking+] security issue fixed by 754202 on m-c
Alias: CVE-2012-3991
Kamil, can you please make an attempt at verifying this is fixed?
Went through the bug and reproduced it with all the versions that we listed above:

Aurora16.0a2 (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-01-04-20-10-mozilla-aurora/
Nightly17.0a1 (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-01-04-20-09-mozilla-aurora/
Firefox Build 16.0.2 (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0.2/win32/en-US/
Firefox Build 17.0 (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0/win32/en-US/
Firefox Build 18.0b1 (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0b1/win32/en-US/
Firefox Build 10.0.11esrpre (Reproduced): http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/

I went through all those builds using the following OS's:
- Windows 7 Home Premium SP1 x64 (Reproduced)
- Windows 7 Home Premium SP1 x86 (Reproduced)
- Windows 8 x86 (Reproduced)

I think the issue has something to do with Adobe Flash (as mentioned in the ticket several times), when Flash isn't installed on the target computer, you will receive the following error in the console:
- TypeError: this.obj is undefined

Once Adobe Flash is installed (in this case, version 11.5.502.110) and Firefox is re-installed, I receive the following error in the console:
- Error: Permission denied to access property 'toString'

I've also created a short video that can be found in the link below to show the issue occurring (being reproduced) on Windows 8 x86 on Firefox 17.0:
- http://screencast.com/t/mJn6tbPhUATa
Thanks a lot Kamil!

Bobby, given these results, I'm not sure how we can verify this is fixed. Please advise.
Keywords: verifyme
Whiteboard: [sg:critical][advisory-tracking+] security issue fixed by 754202 on m-c → [sg:critical][advisory-tracking+][qa?] security issue fixed by 754202 on m-c
Anthony - Throwing the "Permission Denied" is an indicator that the security issue is fixed. The bug summary here is a little confusing, because it was filed as a regression in Aurora but actually indicated that there was a security vulnerability in Beta/Release (that is to say, those _should_ have been throwing the security exception, but they weren't).
Kamil, can you please confirm which of the builds you tested gave a Permission Denied error and which did not? Thanks.
Windows 7 Home Premium x86:

Firefox Build 16.0.2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0.2/win32/en-US/
Aurora16.0a2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-01-04-20-10-mozilla-aurora/
Firefox Build 17.0 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0/win32/en-US/
Nightly17.0a1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-01-04-20-09-mozilla-aurora/
Firefox Build 18.0b1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0b1/win32/en-US/
Firefox Build 10.0.11esrpre - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/

Received "Error: Permission denied to access property 'toString'" on all the above builds

Windows 7 Home Premium x64:

Firefox Build 16.0.2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0.2/win32/en-US/
Aurora16.0a2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-01-04-20-10-mozilla-aurora/
Firefox Build 17.0 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0/win32/en-US/
Nightly17.0a1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-01-04-20-09-mozilla-aurora/
Firefox Build 18.0b1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0b1/win32/en-US/
Firefox Build 10.0.11esrpre - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/

Received "Error: Permission denied to access property 'toString'" on all the above builds

Windows 8 x86:

Firefox Build 16.0.2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/16.0.2/win32/en-US/
Aurora16.0a2 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/08/2012-08-01-04-20-10-mozilla-aurora/
Firefox Build 17.0 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0/win32/en-US/
Nightly17.0a1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/09/2012-09-01-04-20-09-mozilla-aurora/
Firefox Build 18.0b1 - http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/18.0b1/win32/en-US/
Firefox Build 10.0.11esrpre - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-esr10/

Received "Error: Permission denied to access property 'toString'" on all the above builds
Thank you Kamil.

Bobby, based on Kamil's results and your clarification in comment 31, I think this can be marked verified. Do you agree?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #34)
> Thank you Kamil.
> 
> Bobby, based on Kamil's results and your clarification in comment 31, I
> think this can be marked verified. Do you agree?

Yep.
Status: RESOLVED → VERIFIED
status-firefox-esr10: fixed → verified
status-firefox16: fixed → verified
status-firefox17: fixed → verified
status-firefox18: fixed → verified
Whiteboard: [sg:critical][advisory-tracking+][qa?] security issue fixed by 754202 on m-c → [sg:critical][advisory-tracking+]security issue fixed by 754202 on m-c
Group: core-security
rforbes-bugspam-for-setting-that-bounty-flag-20130719
Flags: sec-bounty+

Updated

11 months ago
Duplicate of this bug: 1303344

Updated

11 months ago
See Also: → bug 1303344
You need to log in before you can comment on or make changes to this bug.