Closed Bug 428873 Opened 14 years ago Closed 14 years ago
748 bytes, text/html
597 bytes, application/java-archive
2.39 KB, application/java-archive
813 bytes, application/octet-stream
1.20 KB, patch
|Details | Diff | Splinter Review|
The unsigned version of the same jar which works is available here jar:http://www.blackett.co.nz/chrome_access.jar!/chrome_access.html
Assignee: nobody → dveditz
Product: Firefox → Core
QA Contact: firefox → toolkit
Can you find a 1-day regression range, using builds from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ ?
OK I'll work on that
OK so there is a commit in Bonsai: Just drop loads of scripts that are not signed if the loading page is. Bug 424426, r+sr=jst, a=beltzner I can't see the bug, presumably security related.
It seems to me that we need to be careful not to grant elevated privilege to scripts that are not, however being able to call chrome which independently already has it's own privilege seems important.
So... a patch went in today that prohibits linking to chrome:// scripts at all, though you can white-list your extension. I can see changing the script-blocking thing so that we don't do it when the script channel principal is system. Jonas, Collin, Adam, what do you think?
(In reply to comment #12) > I can see changing the script-blocking thing so that we don't do it when the > script channel principal is system. What is "thing" and "it" in the above sentence?
"nsScriptLoader::ShouldExecuteScript" and "returning PR_FALSE" in that order.
(In reply to comment #12) > So... a patch went in today that prohibits linking to chrome:// scripts at all, > though you can white-list your extension. > > I can see changing the script-blocking thing so that we don't do it when the > script channel principal is system. Jonas, Collin, Adam, what do you think? Since an attacker who can inject content into the system principal can already access your system, I don't see a potential for privilege escalation, so it seems fine to me. To avoid adding a specific exception for the system principal, it might make more sense to use nsIPrincipal::subsumes to determine whether the script channel principal subsumes the signed JAR's principal.
> I don't see the purpose of blocking unsigned scripts from signed jars inside > the same domain The purpose is described in bug Bug 424426 and bug 424188. In brief, if we didn't do that, it would allow some other site to hijack your signed jar and impersonate you to the user. To actually be secure, all the scripts involved need to come from the jar (or from chrome, I guess, per this bug). subsumes() does seem like the way to go here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Testing this depends on bug 424488.
Assignee: dveditz → bzbarsky
Depends on: 424488
Comment on attachment 315687 [details] [diff] [review] Fix Requesting approval. The change here basically just allows signed jars to load chrome:// scripts from content (not skin) packages. It's couched in terms of a generic API call, but in practice existing Subsumes() implementations restrict the change to what's described above. We don't have infrastructure in place to test this yet, unfortunately. :(
Attachment #315687 - Flags: approval1.9?
Comment on attachment 315687 [details] [diff] [review] Fix a=beltzner, left a note on bug 424488 about adding a test at some point
Attachment #315687 - Flags: approval1.9? → approval1.9+
Fix checked in.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I checked the nightly from 17-04-2008 and it does work with both the test example and our original plugin. Thanks. Should I mark this verified myself?
Sure. Thanks for verifying!
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9
You need to log in before you can comment on or make changes to this bug.