Following up on comment 9 on bug 424426 <https://bugzilla.mozilla.org/show_bug.cgi?id=424426#c9>, we did some testing and it appears that stylesheets don't invoke downgrading/blocking rules for codebase principals. If a signed JAR includes <link rel="stylesheet" href="some_relative_path.css"> anywhere inside it, a malicious web site can replace the stylesheet using the JAR-switching technique originally described in comment #1 on bug 424426 <https://bugzilla.mozilla.org/show_bug.cgi?id=418996#c1>. The malicious stylesheet can then use the -moz-binding property to inject script into the page and hijack the signer's privileges. The proof of concept is the "CSS" test case at <http://crypto.stanford.edu/~collinj/research/signed-scripts/more-relative-paths.html>. It is likely that Flash and Java have similar problems.

ccing some more folks who might have bright ideas. I really need to focus on thesis.. As an aside, "bug X comment Y" will get properly linkified to point to that comment by Bugzila.

DVeditz can you take this one?

DVeditz (over email) indicated that we could take this on a dot release since the attack surface is somewhat limited and we are out of time. If I've misrepresented or anyone otherwise disagrees please do re-nom.

So what are we actually planning on doing here? Simply downgrade the principal when a signed jar sinlks to an unsigned stylesheet? The downgrade resulting in removed urlbar indicator and removed lock icon. And removed ability to request elevated privileges?

Downgrading the principal doesn't really work; see Bug 424426. We should probably do the same thing we do for scripts: block loading the resource if it has a different codebase principal.

Boris, can you take a look at this?

This should block 1.9.0.2 but it doesn't look like any progress has been made so it'll probably get pushed...

Pushing this out since it's unlikely to make it, per bz.

Wouldn't it be better to block loading of XBL entirely instead if the page is signed? The AllowScripts thing is mostly there as a leftover from when we tried to stop scripts in skins and ideally should be removed.

You mean if the page is signed and the XBL is not? I think we want to allow loading XBL from the same jar.... the problem is that we don't know at load start time whether it's signed, no? We use AllowScripts to enforce the "JS enabled" preference for untrusted XBL, so I doubt it's going away any time soon...

On second thought, not blocking on this.

Jonas: were you waiting for a new patch or is Boris's answer OK?

Comment on attachment 335410 [details] [diff] [review] Turned out to be easier than I thought Ok, given that it's this simple.

Pushed changeset 7fb158704fe9.

Comment on attachment 335410 [details] [diff] [review] Turned out to be easier than I thought This applies as-is to the 1.9 branch.

Comment on attachment 335410 [details] [diff] [review] Turned out to be easier than I thought Approved for 1.9.0.4, a=dveditz for release-drivers

Comment on attachment 343670 [details] [diff] [review] 1.8 branch version Approved for 1.8.1.18, a=dveditz for release-drivers

Fixed on both branches.

Is there a good way to verify this fix?

Following the directions in comment 0 and the site linked from it?

Doh. Verified for 1.9.0.4 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4pre) Gecko/2008102204 GranParadiso/3.0.4pre using the testcase on the site Verified for 1.8.1.18 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.18pre) Gecko/2008102203 BonEcho/2.0.0.18pre.