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

Status: VERIFIED FIXED

(Core :: Security, defect)

Description

[Shane Blackett]

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.

Comment 1

[Shane Blackett]

Attachment: The test example contained in the jars

Comment 2

[Shane Blackett]

Attachment: Unsigned jar version which works correctly

Comment 3

[Shane Blackett]

Attachment: Signed jar version which doesn't work (Same as URL in original submission).

Comment 4

[Shane Blackett]

Attachment: Public certificate for self signing certificate authority used to sign jar

Comment 5

[Shane Blackett]

The unsigned version of the same jar which works is available here jar:http://www.blackett.co.nz/chrome_access.jar!/chrome_access.html

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Can you find a 1-day regression range, using builds from:

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

?

Comment 7

[Shane Blackett]

OK I'll work on that

Comment 8

[Shane Blackett]

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

Comment 9

[Shane Blackett]

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.

Comment 10

[Shane Blackett]

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/content/base/src&command=DIFF_FRAMESET&root=/cvsroot&file=nsScriptLoader.cpp&rev1=1.118&rev2=1.119

Comment 11

[Shane Blackett]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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?

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(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?

Comment 14

[Boris Zbarsky [:bzbarsky]]

"nsScriptLoader::ShouldExecuteScript" and "returning PR_FALSE" in that order.

Comment 15

[sebastien.courvoisier]

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...) 

Comment 16

[Collin Jackson]

(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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 18

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Testing this depends on bug 424488.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 315687 [details] [diff] [review]
Fix

a=beltzner, left a note on bug 424488 about adding a test at some point

Comment 21

[Boris Zbarsky [:bzbarsky]]

Fix checked in.

Comment 22

[Shane Blackett]

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?

Comment 23

[:Gavin Sharp [email: [e-mail]]]

Sure. Thanks for verifying!