Firefox Hacks [Electronic resources] نسخه متنی

Hack 18. Digitally Sign Content

Content delivered to Firefox can request
special privileges from the user.

Normal Firefox content, whether it's HTML, XHTML or
XUL, runs inside a sandbox that stops it from doing anything risky,
such as modifying files stored on the local disk. This hack explains
how to ask the user for permission to escape the sandbox. If
permission is given, the content (usually scripts) can do
whatever it likes. You can also arrange matters so that the user is
never asked for permission [Hack #19] .

2.9.1. Get Oriented on Security Concepts

The design ideas behind granting permission are
trust and
identity. If the web page content is to have
full control over the browser, there must be trust between the
browser user and the content creatortwo real, live people.
Access to technical features is secondary to this human principle. In
the conservative world of security, trust can be assured only if
identity can be properly determined. Here are the identity
constraints built into
Firefox:

The browser user always knows whom a content maker requesting trust
is.

The browser user can always physically track down a content maker
that requested trust.

The browser user is always free to reject a request for trust.

The Firefox user can drop these constraints if they so choose. When
presented with information about a content maker, the user can tell
Firefox to trust that content maker in the future. That puts identity
information about the content maker in files in the user profile
area. Firefox will always validate signed content, but it can do so
silently if the user directs it to do so.

Validating signed content is done automatically by Firefox. Making
signed content is a task for a web site content creator.

These identity constraints are supported by technologydigital
certificates and digital signingand by a special
sandbox-breaking API that only works when trust is in place. They
also demand some old-fashioned paperwork. A real, live person called
a Certificate Authority (CA) is required. Little of that
infrastructure is obvious or meaningful to an end user confronted by
a permission request, though.

2.9.2. Get Signing Tools

Netscape Security
Services (NSS) is a technology that is part of the Mozilla source
code used to make Firefox. NSS includes a small, separately
downloadable program called signtool. Get it here:

http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/

signtool can combine content (HTML, JavaScript,
XUL, CSS, images, anything) with digital signatures by using
certificates. signtool is incompatible with
similar systems used in Netscape 4.x, Internet Explorer, and Java. It
is good only for Mozilla-based browsers and other software systems
that support it. signtool has some compatibility
with Java, but a second tool called certtool
(http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/)
is also needed.

Signing content is called object
signing, which is different than signing a
certificate. The result of object signing is a JAR file [Hack #86], which contains both content
files and digital signature files.

Signing content is a nuisance for technologists that just want to
build something. Mozilla allows signing to occur in two separate
ways. You can sign in a test environment, where it is easier to use,
or you can sign in a published environment, where it is fully secure.

2.9.3. Sign Content for Test Purposes

In a test environment, two of the three identity requirements can be
dropped. The browser user can be kept ignorant of the content maker.
The browser user is thus unable to track down that person. That
leaves only the requirement that the browser user explicitly grant
permission to the content maker. To enable this weaker security
arrangement:

The content maker uses a special certificate instead of a normal one
from a CA.

The browser user ensures it's OK for Firefox to
accept content signed with that special certificate.

In a test environment, both of these roles are likely to be taken by
one developer. To create the special certificate, first create a
certificate database. Then, make the special object-signing
certificate and put it into the database:

mkdir certs
cd certs
certutil -N -d .
signtool -G '
special
' -p '
password
' -d .

special is the name chosen for the new
certificate. The password string should be
whatever you typed in when certutil ran. Use
single quotes on Linux/Unix to prevent shell reinterpretation.

To tell Firefox it's OK to work with this
certificate, use the following preference:

signed.applets.codebase_principle_support /* set to true. Default = false */

Note the security hole: this setting indicates that content signed with any special certificate (from any web site) will be accepted. The name of this preference is an historical artifact from Netscape 4.x. There is no Java or Java applets at work.

You are now ready to sign your content. Suppose it's
in the directory content, which is a sibling of
the certs directory:

cd ..
signtool -d certs -k '
special
' -p '
password
' -Z result.jar content

The file result.jar is all the signed content.
Put it behind the web server and retrieve it with a URL, or with a
jar: URL. jar: URLs are normally used for chrome packages [Hack #75], but you can put ordinary web
site content in them, too.

2.9.4. Sign Content for Publication

In a production environment, you must have a genuine digital
certificate before you start. Suppose your
organization's name is Acme,
and the certificate comes from the CA Verisign, who gave it this
short name: Acme Cert (Verisign). Once that
certificate is in a handy certificate database [Hack #17], make your object-signing
certificate based on it as follows:

cd certs
signtool -G 'objcert' -k 'Acme Cert (Verisign)' -p '

password

' -d .

Next, sign your content with it. This is the same as in the test
environment, except this time we have a real certificate:

cd ..
signtool -d certs -k 'objcert' -p '

password

' -Z result.jar content

Put the result.jar file on the web server as
before. You're ready to go and
don't need the special preference.

2.9.5. Do Something with Trusted Content

If you've asked the browser user for trust, you must
need it for some reason. There are two things you can do: you can
sign an XPI file,
and you can write scripts that break normal web scripting rules.

If you sign an XPI file, that file can be installed into Firefox from
any web site, provided that the user gives permission. Since an XPI
file and JAR file have the same format, the signing procedure is also
the same. The web site that delivers the XPI file does not need to be
listed as an authoritative source of extensions or patches in this
case.

This sample JavaScript script requests all possible permissions and
then runs some code that wouldn't work in a normal
web page:

function run(  ) {
// normal permissions to start with
critical_section(  )
// normal permissions again
}
// Might be a trusted function, depending on who calls it.
function do_stuff( )
{
var list = window.Components.classes; // try to access XPCOM
}
function critical_section( ) {
// ask the user for permissions; should check return value as well
netscape.security.PrivilegeManager.enablePrivilege(
"UniversalBrowserRead"        + " " +
"UniversalXPConnect"          + " " +
"UniversalPreferencesRead"    + " " +
"UniversalPreferencesWrite"   + " " +
"CapabilityPreferencesAccess" + " " +
"UniversalFileRead"           + " " +
"myCapability");
window.resizeTo(20,20);   // make current window tiny - requires trust.
do_stuff( )                // called with trust in place
} // permissions will end when this function returns
run( ) // do it

The myCapability
option[Hack #20] . See http://www.mozilla.org/projects/security/components/signed-scriptsl
for details on the meaning of all the options.