Closed Bug 428873 Opened 14 years ago Closed 14 years ago

[FIX]Firefox 3 Beta 5 prevents signed jars from accessing chrome javascript

Categories

(Core :: Security, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9

People

(Reporter: shane, Assigned: bzbarsky)

References

()

Details

(Keywords: regression)

Attachments

(5 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

We have been using signed jars with firefox 2 and 3 to access chrome javascript
from our extension.
With Firefox 3 Beta 5 the functions from the chrome are reported as missing in 
the java script error console.
I have created a simple example that does not rely on our extension and
uses the browser chrome instead.  It fails in the same way.
Unfortunately I do not have an externally validated signing certificate,
so I have created my own certificate authority and signed with that.
It is interesting to note that if you do not install my certificate authority
then the jar html will actually work correctly (presumably as the jar 
does not get elevated privilege and so works like a normal page).
This regression makes signed jars in many respects less capable than unsigned ones.


Reproducible: Always

Steps to Reproduce:
1. Install my certificate authority http://www.blackett.co.nz/certs_spark-dental_com.cacert
2. Go to jar:http://www.blackett.co.nz/chrome_access_signed.jar!/chrome_access.html

Actual Results:  
Page is shown but instead of alert an error appears in "Error Console"
Error: getBrowserURL is not defined
Source File: jar:http://www.blackett.co.nz/chrome_access_signed.jar!/chrome_access.html
Line: 14

Expected Results:  
The javascript should have shown an alert with the content
BrowserURL is chrome://browser/content/browser.xul


Tested on linux and windows.
The unsigned version of the same jar which works is available here jar:http://www.blackett.co.nz/chrome_access.jar!/chrome_access.html
Keywords: regression
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Can you find a 1-day regression range, using builds from:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/

?
OK I'll work on that
Broke on 25 March 2008
Fails with
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/2008-03-25-04-trunk/firefox-3.0b5pre.en-US.linux-i686.tar.bz2
(There is an additional javascript error with this build too, which I guess is
unrelated.)
Error: i is undefined
Source File: file:///home/blackett/bin/2008.03.25.firefox-3.0b5pre.en-US.linux-i686/modules/XPCOMUtils.jsm
Line: 115
Failed to load XPCOM component: /home/blackett/bin/2008.03.25.firefox-3.0b5pre.en-US.linux-i686/components/fuelApplication.js

Works for 
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/03/2008-03-24-04-trunk/firefox-3.0b5pre.en-US.linux-i686.tar.bz2
OK so there is a commit in Bonsai:
Just drop loads of scripts that are not signed if the loading page is. Bug
424426, r+sr=jst, a=beltzner 

I can't see the bug, presumably security related.
It seems to me that we need to be careful not to grant elevated privilege to scripts that are not, however being able to call chrome which independently already has it's own privilege seems important.
So... a patch went in today that prohibits linking to chrome:// scripts at all, though you can white-list your extension.

I can see changing the script-blocking thing so that we don't do it when the script channel principal is system.  Jonas, Collin, Adam, what do you think?
(In reply to comment #12)
> I can see changing the script-blocking thing so that we don't do it when the
> script channel principal is system.

What is "thing" and "it" in the above sentence?

"nsScriptLoader::ShouldExecuteScript" and "returning PR_FALSE" in that order.
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

I have the same issue with signed jars loading unsigned javascript files from the same domain.

For example, the XUL document jar:http://some.domain.com/signed.jar!/signed.xul used to include some libraries from the same domain but outside of the jar package (<script src="http://some.domaine.com/somelib.js"></script>). 

Now they're still loaded, but all their objects and classes are unaccessible ("not defined").

I don't see the purpose of blocking unsigned scripts from signed jars inside the same domain... (it only harms XUL webapps, but I know it's nothing but a marginal topic now...) 
(In reply to comment #12)
> So... a patch went in today that prohibits linking to chrome:// scripts at all,
> though you can white-list your extension.
> 
> I can see changing the script-blocking thing so that we don't do it when the
> script channel principal is system.  Jonas, Collin, Adam, what do you think?

Since an attacker who can inject content into the system principal can already access your system, I don't see a potential for privilege escalation, so it seems fine to me. To avoid adding a specific exception for the system principal, it might make more sense to use nsIPrincipal::subsumes to determine whether the script channel principal subsumes the signed JAR's principal.
> I don't see the purpose of blocking unsigned scripts from signed jars inside
> the same domain

The purpose is described in bug Bug 424426 and bug 424188.  In brief, if we didn't do that, it would allow some other site to hijack your signed jar and impersonate you to the user.  To actually be secure, all the scripts involved need to come from the jar (or from chrome, I guess, per this bug).

subsumes() does seem like the way to go here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached patch FixSplinter Review
Testing this depends on bug 424488.
Attachment #315687 - Flags: superreview?
Attachment #315687 - Flags: review?
Assignee: dveditz → bzbarsky
Depends on: 424488
Summary: Firefox 3 Beta 5 prevents signed jars from accessing chrome javascript → [FIX]Firefox 3 Beta 5 prevents signed jars from accessing chrome javascript
Attachment #315687 - Flags: superreview?(jst)
Attachment #315687 - Flags: superreview?
Attachment #315687 - Flags: review?(jst)
Attachment #315687 - Flags: review?
Attachment #315687 - Flags: superreview?(jst)
Attachment #315687 - Flags: superreview+
Attachment #315687 - Flags: review?(jst)
Attachment #315687 - Flags: review+
Comment on attachment 315687 [details] [diff] [review]
Fix

Requesting approval.  The change here basically just allows signed jars to load chrome:// scripts from content (not skin) packages.  It's couched in terms of a generic API call, but in practice existing Subsumes() implementations restrict the change to what's described above.

We don't have infrastructure in place to test this yet, unfortunately.  :(
Attachment #315687 - Flags: approval1.9?
Comment on attachment 315687 [details] [diff] [review]
Fix

a=beltzner, left a note on bug 424488 about adding a test at some point
Attachment #315687 - Flags: approval1.9? → approval1.9+
Fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I checked the nightly from 17-04-2008 and it does work with
both the test example and our original plugin.
Thanks.
Should I mark this verified myself?
Sure. Thanks for verifying!
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.