Closed Bug 249038 Opened 20 years ago Closed 20 years ago

Self-signed remote XUL still treated as untrusted

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: deepgloat, Unassigned)

Details

Attachments

(1 file)

testjar.jar is the signed JAR containing the test XUL and HTML files
2.35 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616

XUL loaded from a self-signed JAR is treated as untrusted in Mozilla 1.7. The
height and width attributes of the window are unavailable, as is the title
attribute. According to bug #248008, remote XUL should be signed to access these
attributes.


Reproducible: Always
Steps to Reproduce:
(1) Run the certutil utility to create a certificate database (we put ours in a
subfolder named "cert" with a password of "bluebird1234"):

C:\apache.org\Apache\cert>certutil -N -d cert

(2) Run signtool to create a new test certificate (we called ours "testcert"):

C:\apache.org\Apache\cert>signtool -G testcert -d cert -p bluebird1234
using certificate directory: cert

WARNING: Performing this operation while the browser is running could cause
corruption of your security databases. If the browser is currently running,
you should exit the browser before continuing this operation. Enter
"y" to continue, or anything else to abort: y

Enter certificate information.  All fields are optional. Acceptable
characters are numbers, letters, spaces, and apostrophes.
certificate common name: Test Object Signing Certificate
organization: Acme Widgets Inc
organization unit: Web Systems Group
state or province: VA
country (must be exactly 2 characters): US
username: deepgloat
email address: deepgloathatesspam@yahoo.com
generated public/private key pair
certificate request generated
certificate has been signed
certificate "testcert" added to database
Exported certificate to x509.raw and x509.cacert.

(3) Run signtool again to ensure that an object-signing certificate is in the
database:

C:\apache.org\Apache\cert>signtool -L -d cert
using certificate directory: cert

S Certificates
- ------------
* testcert
- ------------
Certificates that can be used to sign objects have *'s to their left.

(4) Create an empty directory for signing files:

C:\apache.org\Apache\cert>md signdir

5) Copy the files to be signed into the directory. We have two files for this
test, test.html and xulwin.xul:

<!-- test.html -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<style>
</style>
<script>
function loadxul(url) {
    window.open(url+".xul",null,"chrome,resizable,centerscreen,dependent,dialog");
}
</script>
</head>
<body>
<input type="button" value="Load XUL Test Window" onclick="loadxul('xulwin')">
</body>
</html>

<!-- xulwin.xul -->
<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<!DOCTYPE window>
<window id="myid"
    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
    title="My Window" width="250px" height="250px">
    <box>
        <description>Hello world!</description>
    </box>
</window>

(6) Sign the directory:

C:\apache.org\Apache\cert>signtool -d cert -k testcert -p bluebird1234 -Z
testjar.jar signdir
using certificate directory: cert
Generating signdir/META-INF/manifest.mf file..
--> test.html
adding signdir/test.html to testjar.jar...(deflated 30%)
--> xulwin.xul
adding signdir/xulwin.xul to testjar.jar...(deflated 28%)
Generating zigbert.sf file..
adding signdir/META-INF/manifest.mf to testjar.jar...(deflated 28%)
adding signdir/META-INF/zigbert.sf to testjar.jar...(deflated 36%)
adding signdir/META-INF/zigbert.rsa to testjar.jar...(deflated 36%)
tree "signdir" signed successfully

(7) Test the archive:

C:\apache.org\Apache\cert>signtool -d cert -v testjar.jar
using certificate directory: cert
archive "testjar.jar" has passed crypto verification.

          status   path
    ------------   -------------------
        verified   test.html
        verified   xulwin.xul

(8) Copy the JAR file to your webserver. In Mozilla 1.7, navigate to the JAR
using the jar:http syntax:

jar:http://localhost/testjar.jar!/test.html

(9) Click the "Load XUL Test Window" button.
Actual Results:  
The xulwin.xul test window incorrectly opens in a large browser window and its
title in the title bar says "Mozilla".

Expected Results:  
The test window should have honored the specified width and height attributes of
250px each, and the titlebar should have said "My Window" instead of "Mozilla".

By the way, we noticed in the script signing instructions some discussion about
calling
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserAccess"). We
couldn't tell whether this was needed inside of a signed script, so when the XUL
window wasn't opening correctly we decided to modify the loadxul() function in
test.html to try it out:

function loadxul(url) {
    try {      
netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserAccess");
    }
    catch (e) {
        alert(e);
    }
    window.open(url+".xul",null,"chrome,resizable,centerscreen,dependent,dialog");
} 

When we did this, we caught the following exception: 

A script from "jar:http://localhost/testjar.jar!/test.html" was denied
UniversalBrowserAccess privileges. 

So obviously we're not supposed to call **that** function.

We're at our wits' end here. First Mozilla 1.7 stops allowing us to control the
appearance of our remote XUL windows, and now--after following the
recommendation to sign our XUL and spending almost two days puzzling through a
hodgepodge of instructions--we are still unable to get our remote XUL windows to
work correctly. VERY frustrating.
NOTE: The bug number I mentioned in the first paragraph was mistyped; it was the
comments in bug #248004 that recommended signing remote XUL. Thanks.
Can you attach your signed JAR to the bug?

I still think it would be easier to make intrisic width and height work for
untrusted content, rather than making everybody use signed JARs and request
enhanced privileges.
This is the signed JAR file that we created to test signing remote XUL.
(In reply to comment #2)
> Can you attach your signed JAR to the bug?
> 
> I still think it would be easier to make intrisic width and height work for
> untrusted content, rather than making everybody use signed JARs and request
> enhanced privileges.
Benjamin: It's not just the width/height issue anymore... it turns out that our
designers *don't* want " - Mozilla" appended to the titles in our XUL windows,
which means that we can't use document.title after all. Also, I'm concerned that
the signing mechanism doesn't appear to work as advertised--what are we going to
do when the Mozilla developers clamp down on even more XUL features for
untrusted content if JAR signing doesn't work?
When I open the html file and click on the button I get on the JS Console:

Signature Verification Error: the signature on xulwin.xul is invalid because the
certificate used to sign this file has an unrecognized issuer.

Are you using a real certificate or just a test one?

The instructions for reproducing this bug make it very clear that this is a test
certificate... the first three steps of the instructions are the steps for
creating the certificate database and the test certificate.

Are you saying that Mozilla won't accept anything except signed JARs that are
signed with a certificate issued by someone like Verisign? If so, that's a
little impractical for development work! Shouldn't Mozilla instead pop up some
warning that the JAR you're using is signed by an unknown agent? That's what
happens when you try to install an XPI that is signed by an unknown authority.
Scott,

Neil points to the answer. Here's the long form:

The problem is that the test certificate is its own
certificate authority. It doesn't contain a digital signature/key of
a 3rd party certificate authority (CA); it only contains its own signature.
It's a sort of /dev/null or recursive certificate.

When the signed content is downloaded, the signatures are compared
against the CA database provided with Mozilla/Firefox. Since the
test-certificate-as-own-CA isn't in that database (which contains only
real and genuine CAs), permission to exploit codebase principles
isn't granted, because the test certificate's CA is "unknown". Fail.

In a test environment, where a test certificate is used, the
pref. "signed.applets.codebase_principle_support" = true is
required client-side to overcome this obstacle. It's meant for
testing only.

In a production environment, you must have a real certificate whose
CA signature matches a CA already bundled with Mozilla. Your
only CA choices are CAs bundled with Mozilla. That, however, is
all of the CAs except for private ones like banks.

This obstacle is in place so that malicious people can't act
just like developers and rule the browser with a bogus test
certificate, generated just as you have generated it.
They have to go out and get a real one, identifying themselves
in the real world to the certificate authority. That's enough
to ensure that the browser user can't be made subject to fraud,
at least not without traceability straight back to the certificate
applicant - police, dogs, broken down doors, everything.

Can you please re-test as a test environment with the pref in place?

Can you then ask a real CA for a "test certificate". That's a real
and genuine certificate, but with a very short expiry time, like 30 days. 
Such a thing should be free and deliverable by email.
Tell them you're evaluating CA technology. After you've got it, re-sign
the content with it instead of with the bogus cert, then unset the pref
and test in "production environment mode" with that?

Hopefully that will show "it all works". The pref is there only to support
developers and testing. It also explains why setting the pref doesn't
shut up the dialog boxes the user gets - the pref is not a holiday
ticket to freedom, it just overcomes the problem of bogus test certificates.

As Neil pointed out, the error message you get is in the JS Console.
Bogus test certificates "never" appear in production environments, so
there's no need for a dialog box.

Sorry this comment is late. Closing here.
Re-open if you've still got problems.

- N.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: