424190 - Unsigned JARs can inject script into signed JARs that use relative paths

Status: RESOLVED DUPLICATE of bug 424188

(Core :: Security: CAPS, defect)

Description

[Collin Jackson]

If a signed JAR file includes <script src="some_relative_path.js"> anywhere inside it, an attacker's web site can hijack that JAR's privileges in a similar attack to the one described in bug 418996.

To accomplish this, the attacker serves up a different JAR file on subsequent loads for the same JAR file URL, sometimes displaying the victim's signed JAR, and other times displaying the attacker's JAR. This tricks the victim's signed JAR file into embedding the attacker's script using a relative path.

Firefox extensions are distributed as JAR files with the XPI extension. Here's
an example attack against a signed Stanford Firefox extension:

http://crypto.stanford.edu/~collinj/research/signed-scripts/relative-path.html

The only thing that the signed victim extension needs to do for the attack to
work is to embed <script src="some_relative_path.js"> in one of its XUL files.
By sending "Cache-Control: no-cache" headers and replying with a different JAR
file, the attacker can substitute a different (unsigned) file for some_relative_path.js.

Relative path attacks on signed XPI files are mitigated by two factors:

1) XUL files are often JAR'd a second time in an unsigned JAR file in the
chrome/ directory, which seems to prevent the browser from treating the XUL
document as signed.
2) Extension authors seem to prefer absolute chrome:// URLs to relative paths,
even for files in the same directory.

Because of these mitigating factors, only some XPI files are vulnerable to relative path attacks. However, signed JARs that are not XPIs (which are the ones that are supposed to be using enablePrivilege in the first place) are very likely to include script using a relative path.

This issue was originally described in a comment on bug 418996.

Comment 1

[Collin Jackson]

Looks like Boris has already filed this...