Created attachment 253882 [details] testcase 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:220.127.116.11pre) Gecko/20070203 BonEcho/18.104.22.168pre
10 years ago
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.
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.
Created attachment 268472 [details] testcase 2 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.)
Created attachment 268528 [details] [diff] [review] Proposed fix 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.
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
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.
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?
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 22.214.171.124 and 126.96.36.199, a=dveditz
Fix checked into the 1.8 branches.
verified fixed 188.8.131.52 using Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2007071216 Firefox/220.127.116.11 and the testcases from this bug.
Verified on Thunderbird version 18.104.22.168 (20070809) on an XP (vm) with testcases in comment #0 and comment #4.