Implicit XPCNativeWrapper, a wrapper object to provide a safe way to access untrusted content DOM from chrome, can be polluted by that untrusted content. steps: 1. load the attached testcase. 2. middle click on the content to start auto scrolling. 3. you will see an alert if there is a bug. Mozilla/5.0 (Windows; U; Win98; en-US; rv:18.104.22.168pre) Gecko/20070203 BonEcho/22.214.171.124pre
Assignee: dveditz → jst
Flags: blocking1.9? → blocking1.9+
This is basically another variant of what's discussed in bug 363891. Content fools chrome code into calling eval indirectly, and gets it to eval untrusted script from chrome.
While the testcase in this bug is fixed by mrbkap's eval() changes we think it's still vulnerable to alternatives. Reassigning to mrbkap for him to have a deeper look at this.
Assignee: jst → mrbkap
In particular, we were wondering if we could replace 'eval' with a location setter, or something, which would allow similar access to the implicit XPCNativeWrapper. I'm CCing moz_bug_r_a4 since he seems to eat these sort of testcases for breakfast.
It's possible to use 'eval' with a window. (If I replace 'eval' with a location setter, |window.parent.document| is not the implicit XPCNativeWrapper.)
This patch is a bit of a hack but it works. The main problem here is that the script that eval creates inherits its scripted caller's script filename. Because of this, even though we find the right principals for the script, we still think that it's from the chrome XBL binding. This patch makes us use the codebase of the principals that we're using if we didn't end up using the caller's. I'm hoping that this situation is rare enough that nobody is going to care.
Attachment #268528 - Flags: review?(brendan)
Status: NEW → ASSIGNED
Comment on attachment 268528 [details] [diff] [review] Proposed fix r=me, wondering what the possible values of principals->codebase, e.g., for the system principal? /be
Attachment #268528 - Flags: review?(brendan) → review+
I looked into this, and the system principal uses the string "[System Principal]" for its codebase. It's not a great filename, but I don't think that we can get into this codepath with the system principal anyway.
Fix checked into trunk. I noticed that this doesn't have security markings ([sg:*]) but is in the security group. These two facts seem disjoint to me.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
As a member of the security group feel free to take your best shot at a sg: marking without waiting for me to do it. Your evaluation is likely to involve less guessing than mine. Is this OK to take on branch?
Whiteboard: [sg:moderate?] severity would depend on what the chrome in question was doing
Test for this in test suite? What's the process for adding tests for sg: bugs?
Comment on attachment 268528 [details] [diff] [review] Proposed fix This applies to the 1.8 and 1.8.0 branches as-is.
Comment on attachment 268528 [details] [diff] [review] Proposed fix approved for 126.96.36.199 and 188.8.131.52, a=dveditz
verified fixed 184.108.40.206 using Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) Gecko/2007071216 Firefox/18.104.22.168 and the testcases from this bug.
Verified on Thunderbird version 22.214.171.124 (20070809) on an XP (vm) with testcases in comment #0 and comment #4.
Whiteboard: [sg:moderate?] severity would depend on what the chrome in question was doing → [sg:moderate?] keep private until 363891 fixed on branch. severity would depend on what the chrome in question was doing
You need to log in before you can comment on or make changes to this bug.