Blake: Weren't XOW supposed to protect us from this? (Note: The JS in step 4 doesn't actually work for me, but step 5 definitely does.)
It's "moderate" because we don't know of any Firefox dialogs that will open random pages in this way. There is quite a bit of mitigation value if an attacker has to tell the user 1) open the about dialog 2) click the license link 3) now please come visit my page in that window (type the URL, paste it, use a bookmark) It's more likely that some add-on somewhere is doing something like this although we don't know of any specific examples. It would be an sg:critical bug for users of that add-on. Does that make it sg:critical overall? Always? Only if the addon is really popular? I don't know, maybe. I guess that's a long-winded "yes" to your question.
It's not 'any' window opened by 'any' chrome dialog. New windows opened from the bookmarks/history dialog don't do this, for instance. Is it limited to XUL <label class="text-link"> links?
(In reply to comment #1) > Blake: Weren't XOW supposed to protect us from this? (Note: The JS in step 4 > doesn't actually work for me, but step 5 definitely does.) Sort of -- the problem is that the object we're handing out is *so* wrong, XOWs don't even notice.
Created attachment 407407 [details] [diff] [review] Proposed fix Easy fix: don't return an opener if we're not chrome and the window that we're returning is a chrome window (even content windows with chrome privileges get wrapped and protected).
Created attachment 407408 [details] [diff] [review] Assertion I don't want to land this at the same time as attachment 407407 [details] [diff] [review] because I think this assertion + that fix make the problem here extremely obvious to interested onlookers. This assertion checks to make sure that we don't ever try to wrap a chrome window in a content scope. As a belt and braces, we could either throw in these cases, or wrap all [object ChromeWindow]s in SystemOnlyWrappers.
Blake, can you land this for trunk and 1.9.2?
http://hg.mozilla.org/mozilla-central/rev/2a7e710043b6 and http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d9ea184f0558 are your answers.
Comment on attachment 407407 [details] [diff] [review] Proposed fix Does the lack of a 188.8.131.52 approval request mean we need a different back-port? Or just an oversight?
Comment on attachment 407407 [details] [diff] [review] Proposed fix In this case it means that I forgot to request approval.
Comment on attachment 407407 [details] [diff] [review] Proposed fix Approved for 184.108.40.206 and 220.127.116.11, a=dveditz for release-drivers
Fixed in CVS.
Verified fixed in 18.104.22.168 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20091119 Shiretoko/3.5.6pre (.NET CLR 3.5.30729) using steps in comment 0. Used steps in comment 5 for 126.96.36.199 since the licensing link doesn't exist in 1.9.0. Verified fixed for 188.8.131.52 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2009111921 GranParadiso/3.0.16pre (.NET CLR 3.5.30729).
I had to back that out because we hit it on tinderbox alive tests... http://hg.mozilla.org/mozilla-central/rev/61cd29e06840
Comment on attachment 407408 [details] [diff] [review] Assertion Sadly, we can't do this. Given code like: var chromeWin = aWindow .QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIWebNavigation) .QueryInterface(Ci.nsIDocShellTreeItem) .rootTreeItem .QueryInterface(Ci.nsIInterfaceRequestor) .getInterface(Ci.nsIDOMWindow) .QueryInterface(Ci.nsIDOMChromeWindow); on a content window (through an XPCNativeWrapper, even), we start in a content scope (the window)... when GI to docshelltreeitem, we create a docshell JS object in the scope we think we're in (i.e. the content window), then when we get the DOMWindow from that, we wrap it in the current scope, which is still the content window... But it's not *really* in that scope, we just think it is.