Closed Bug 424733 (CVE-2008-5023) Opened 13 years ago Closed 12 years ago
[FIX]CSS -moz-binding property bypasses security checks on codebase principals
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?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
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.
Assignee: dveditz → nobody
Assignee: nobody → dveditz
Priority: P2 → P1
Boris, can you take a look at this?
Assignee: dveditz → bzbarsky
This should block 18.104.22.168 but it doesn't look like any progress has been made so it'll probably get pushed...
Flags: blocking22.214.171.124? → blocking126.96.36.199+
Whiteboard: [sg:high] → [sg:high][needs patch]
Pushing this out since it's unlikely to make it, per bz.
Summary: CSS -moz-binding property bypasses security checks on codebase principals → [FIX]CSS -moz-binding property bypasses security checks on codebase principals
Whiteboard: [sg:high][needs patch] → [sg:high]
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.
Flags: blocking1.9.1+ → blocking1.9.1-
Jonas: were you waiting for a new patch or is Boris's answer OK?
Whiteboard: [sg:high] → [sg:high] needs r=jonas
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 335410 [details] [diff] [review] Turned out to be easier than I thought This applies as-is to the 1.9 branch.
Attachment #335410 - Flags: approval188.8.131.52?
Comment on attachment 335410 [details] [diff] [review] Turned out to be easier than I thought Approved for 184.108.40.206, a=dveditz for release-drivers
Attachment #335410 - Flags: approval220.127.116.11? → approval18.104.22.168+
Comment on attachment 343670 [details] [diff] [review] 1.8 branch version Approved for 22.214.171.124, a=dveditz for release-drivers
Attachment #343670 - Flags: approval126.96.36.199? → approval188.8.131.52+
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 184.108.40.206 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:220.127.116.11pre) Gecko/2008102204 GranParadiso/3.0.4pre using the testcase on the site Verified for 18.104.22.168 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:22.214.171.124pre) Gecko/2008102203 BonEcho/126.96.36.199pre.
You need to log in before you can comment on or make changes to this bug.