1.54 KB, text/html
1.66 KB, text/html
1.64 KB, text/html
1.08 KB, text/html
4.30 KB, text/html
This vulnerability was found and exploited by some tests of Jordi Chancel (me) and Eddy Bordi (Researcher at Alternativ-Testing.fr and Consultant of Vulnerability.fr).
For using this testcase => http://www.alternativ-testing.fr/Research/Mozilla/Mozilla%20Firefox%20High%20URL%20SSL%20TLS%20Bar%20Spoof6sd874c9dsc94x8d8972x/url1.html , you should accept popups from this website, thanks.
Confirming this bug. The testcase in comment 2 leads to very bizarre behavior, but I'm not sure yet if it's useful as an exploit. Clicking that URL and dismissing the alert seems to open and close a google tab that winds up painted in the space where the opener tab used to be, but without any usable UI. You cannot click links, interact with the form, get a context menu, open the Web Console, or do just about anything with the page. If you switch focus to another tab, you "lose" the spoofed tab. The location bar is spoofed, sure. But what would the value be to an attacker if you can't interact with the page at all? I'm having a hard time rating this one. CC'ing Gavin since there are also some uncaught exceptions in browser.xml relating to switching and closing tabs that could potentially lead to other problems.
@Brandon Sterne : with the new testcase 0.2 => http://www.alternativ-testing.fr/Research/Mozilla/Mozilla%20Firefox%20High%20URL%20SSL%20TLS%20Bar%20Spoof6sd874c9dsc94x8d8972x/2/url1.html , I can click links, interact with the form, get a context menu, open the web console etc... Please use this new testcase please , i go post a video for demonstrate this.
So view this video => http://www.youtube.com/watch?v=Ma_InlJsxls sg:Moderate or sg:High ?
I can confirm the behavior in comment 7. Once the Google tab is closed, the tab goes away but the navigation bar stops updating. So if you do happen to navigate this zombie tab (through content only, e.g. following links) the location bar will continue to say Google. This is clearly a bug, but I am still unconvinced as to its value as part of an attack. Sure, you can open a page to banking-site.com, but in order for the victim to enter anything sensitive into a phishing site, they would have to navigate this zombie tab over to the phishing site themselves, and only by following links from the banking-site. I don't see how that could reasonably happen. Of course you could also make a user go to attacker-site.com and have them navigate away while still thinking they're on attacker-site.com, but I don't see how that has any value either. Am I missing some part of the attack?
Yes, but it's possible for attacker.com to show the google.com content automaticaly. So I think this can be inversed and google.com can automaticaly show attacker.com content (not demonstrated yet) . I will try to code a proof of concept wich demonstrates this.
moz_bug_r_a4: we're clearly in an odd state here. Can you find a way to abuse it?
The odd state is probably more in content-land than up in the tabbrowser front-end code.
This actually looks like mostly a tabbrowser issue, caused in part by a strange interaction with tab-modal prompts. I saw a couple of "this.selectedTab is null" exceptions, which certainly shouldn't be happening. I haven't had a chance to look into it further.
(In reply to Brandon Sterne (:bsterne) from comment #9) > I can confirm the behavior in comment 7. Once the Google tab is closed, the > tab goes away but the navigation bar stops updating. So if you do happen to > navigate this zombie tab (through content only, e.g. following links) the > location bar will continue to say Google. > > This is clearly a bug, but I am still unconvinced as to its value as part of > an attack. Sure, you can open a page to banking-site.com, but in order for > the victim to enter anything sensitive into a phishing site, they would have > to navigate this zombie tab over to the phishing site themselves, and only > by following links from the banking-site. I don't see how that could > reasonably happen. > An attacker's script can navigate a zombie tab to a phishing site. I'll attach a phishing testcase.
Thanks @firstname.lastname@example.org ! So this testcase works with user interaction for close the tab but this new Proof of Concept is better than the testcase 0.2 . what is the severity of this issue ? [sg:low]? [sg:moderate]? [sg:high]? I think that this new vulnerability can be high or in the worst case moderate isn't it?
If we redirect the user to a blank page without any interaction possible (example https://accounts.google.com/ServiceLogin%), he will close the tab in most of case.
Video of the new Testcase without close a tab manually => http://www.youtube.com/watch?v=3XobLRzLsOk
I had a similar testcase that worked with Firefox 8.0 that automatically closed a tab and loaded a fake page. But, I could not find a way to do phishing in a fake page without JS and forms. Now, I noticed that a subframe's JS and forms can work even when a tab is automatically closed. I'll attach two testcases that work with trunk, 8.0 and 3.6.
Created attachment 574265 [details] phishing testcase 3 This works without user interaction. But, this works only if a user disabled the pop-up blocker or allowed pop-ups for this site.
Gavin: please find someone on the Firefox team to own this bug. Thanks!
The basic setup for the test case is: - the content document's body onblur has a call to window.alert() in it - that content window is window.close()d The sequence of events here is: - close() triggers the tab removal code (via "DOMWindowClose") - tabbrowser's _endRemoveTab calls _blurTab, which calls the selectedTab setter (selecting the owner in this case) - that ends up firing a select event, which triggers updateCurrentBrowser, which updates focus - the update of focus triggers onblur on the content document, which triggers the alert() - now the the tabmodal prompts code is triggered, but for a tab that we're still in the process of removing (has already been collapsed). this results in the prompt-with-no-selected tab UI glitch. From then on, tabbrowser is basically very confused. I haven't tracked down all of the issues, but re-entering tabbrowser code from within _endRemoveTab leads to badness all over the place. I'm not sure what the best way to fix this is. I think we want to generally avoid showing prompts after tabbrowser decides it's going to be closing the tab, but since it does that in reaction to DOMWindowClose, there isn't currently an easy way to propagate that information back to the window (so that it can throw in response to alert()/prompt() etc.). Maybe we need to add one?
(In reply to Gavin Sharp (use email@example.com for email) from comment #29) > From then on, tabbrowser is basically very confused. I haven't tracked down > all of the issues, but re-entering tabbrowser code from within _endRemoveTab > leads to badness all over the place. The main issue in this case is actually that the tabbox selectedIndex setter re-enters itself, since the tab modal prompter triggers DOMWillOpenModalDialog, which in turns sets selectedTab.
Created attachment 577785 [details] [diff] [review] hacky workaround This works around the issue, by refusing to show a prompt for a tab that is closing (I think this breaks beforeunload, so it's not suitable for landing). It also doesn't prevent the prompt early enough to prevent DOMWillOpenModalDialog from firing, so I needed to add a check for closing tabs there too.
Comment on attachment 577785 [details] [diff] [review] hacky workaround >diff -r 95bca70369ef browser/base/content/tabbrowser.xml >- this.selectedTab = this._getTabForContentWindow(event.target.top); >+ let tab = this._getTabForContentWindow(event.target.top); >+ if (!tab.closing) >+ this.selectedTab = tab; Hmm, this change seems to be sufficient for fixing the current testcases, despite not solving the root issue. It's nicely isolated, too, so it might be a suitable workaround for branches.
Gavin, thanks for the awesome summary! By the time DOMWindowClose is firing have we committed to closing the window/tab? I mean, beforeunload will still fire after DOMWindowClose and whatnot, but can the window actually say up?
(In reply to Boris Zbarsky (:bz) from comment #33) > By the time DOMWindowClose is firing have we committed to closing the > window/tab? I mean, beforeunload will still fire after DOMWindowClose and > whatnot, but can the window actually say up? Not fully... the tabbrowser DOMWindowClose handler doesn't close the tab if: - there is only one tab left - the docshell's DocumentViewerImpl::PermitUnload() returns false.
The one tab case also doesn't preventDefault and then we close the window ourselves. The PermitUnload is worse; that means that a beforeUnload handler can prevent the close. Adding an explicit way for tabbrowser to tell the window "you're closing now; no more alerts" seems fine to me.
That said, simply removing the <browser> from the DOM should do that now. Are we calling updateCurrentBrowser before said removal?
(In reply to Boris Zbarsky (:bz) from comment #36) > That said, simply removing the <browser> from the DOM should do that now. > Are we calling updateCurrentBrowser before said removal? Yes - we update the UI (i.e. collapse the old tab and switch tabs) before removing the <browser>, since apparently that can be slow.
OK, adding a way to notify the window once we have committed to closing it is the simplest approach here, I think.
Created attachment 578105 [details] [diff] [review] disable dialogs for closing tabs I don't understand the current conditional in nsGlobalWindow::AreDialogsBlocked - not sure why it bothers checking the PopupControlState or mDialogAbuseCount - it was preventing me from simply using PreventFurtherDialogs, so I changed it.
Comment on attachment 578105 [details] [diff] [review] disable dialogs for closing tabs Oh, I think I figured out why the check is the way it is - the intent was to presumably only "prevent further dialogs" while the popup blocking state is in effect, so that a window can eventually regain the ability to show dialogs despite PreventFurtherDialogs having been called. I'm not sure how useful that is...
Comment on attachment 578105 [details] [diff] [review] disable dialogs for closing tabs General idea seems fine, but I'm not sure about the change to AreDialogsBlocked. Why not just add another boolean to track this hard block instead?
Created attachment 578387 [details] [diff] [review] patch Here's a patch with a separate flag. This stuff still seems a little too convoluted...
Comment on attachment 578387 [details] [diff] [review] patch r=jst, and I agree this stuff is a bit convoluted, but that's material for a different bug whenever it's time to clean up here.
So one of the side effects of this change is that it fixes bug 391834, for onunload/onpagehide. I noticed this because it triggers a leak in browser_tabview_bug626455.js, which registers three window listeners because it expects three dialogs on tab closing. With this patch it only gets one, so the two other listeners leaked the window. Given bug 664586, I tend to think we should fix (at least those cases of) bug 391834 anyways, so I think I'll just move my patch there.
(In reply to Gavin Sharp (use firstname.lastname@example.org for email) from comment #44) > So one of the side effects of this change is that it fixes bug 391834, for > onunload/onpagehide. Although only for the tab closing case, not for other triggers of unload/pagehide (like page navigation). I'll need to find a way to fix that separately.
We still do need a fix for this. How's it coming in bug 391834?
(In reply to Daniel Veditz [:dveditz] from comment #47) > We still do need a fix for this. How's it coming in bug 391834? No progress since my last comments. I don't think we'd want bug 391834 on branches, so I probably need to investigate a more isolated fix here.
Hmm. See also bug 650704 comment 2.
Let's track for ESR once this is fixed on mainline.
(In reply to Gavin Sharp (use email@example.com for email) from comment #48) > I don't think we'd want bug 391834 on branches, so I probably need > to investigate a more isolated fix here. Does it help that we don't have to worry about 1.9.2 anymore? esr10 is the oldest branch, although such a behavior change might be a surprise on an ESR.
Even just fixing it on mainline would be a win. Gavin, how much easier is the world if we just fix trunk?
There are no easy fixes, trunk or otherwise. A variant of attachment 577785 [details] [diff] [review] per comment 32 may be adequate for solving the most pressing issues (it would make some of these testcase "less bad"), but it wouldn't be a complete fix. I think to address the root causes we need to fix bug 391834, which probably isn't going to happen in the near future (and certainly not on aurora/beta/ESR). I have been meaning to investigate workarounds, but I haven't yet been able to find the time to do so.
(In reply to :Gavin Sharp (use firstname.lastname@example.org for email) from comment #53) > There are no easy fixes, trunk or otherwise. A variant of attachment 577785 [details] [diff] [review] > [details] [diff] [review] per comment 32 may be adequate for solving the > most pressing issues (it would make some of these testcase "less bad"), but > it wouldn't be a complete fix. > > I think to address the root causes we need to fix bug 391834, which probably > isn't going to happen in the near future (and certainly not on > aurora/beta/ESR). I have been meaning to investigate workarounds, but I > haven't yet been able to find the time to do so. Is there someone else we should ask to do so, in your stead?
Yes, this is on my list of bugs that I need to get fixed.
This should have been fixed on trunk by bug 391834.
Looks like that landed in 17, not 16.
Oops, yes, hit the wrong flag. Thanks for catching that.
Is there any reason to believe the situation in Comment 53 has changed at all now that bug 391834 is resolved? We're trying to figure out whether to wontfix for ESR10, and we're getting the feeling this will be first fixed in ESR17.
(In reply to Alex Keybl [:akeybl] from comment #59) > Is there any reason to believe the situation in Comment 53 has changed at > all now that bug 391834 is resolved? We're trying to figure out whether to > wontfix for ESR10, and we're getting the feeling this will be first fixed in > ESR17. I think comment 53 is still accurate. We don't want to backport bug 391834 to ESR.
I have reported this vulnerability last year and now there is no fix for this vuln.... Please make a security update for this vulnerability... it's too long...!!!
The fix for bug 391834 is too invasive and risky to take in a security update. This will be fixed in Firefox 17.
Created attachment 661832 [details] Firefox 15.0.1 PoC Url/SSL Spoofing with the update , some of old poc are not exploitable (input aren't writable). This new PoC works very well
Jordi: if you're still able to trigger some kind of bad behavior, please file a new bug. It's hard to track multiple issues within one bug, especially when they've already been fixed. File a new bug and refer back to this one.
I filed bug 793047 for that.
Confirmed broken on build 2011-11-5, 10.0a1 Verified fixed on build 2012-10-23, 17.0b3 Mac 10.8.2, Windows 7 and Ubuntu 11.10
Marking this as not tracking for a 17 advisory since it is embargoed until ESR10 EOL.
this bug is fixed on the last update but i don't see my name in an advisory??? Can you reply quickly please?
See comment 68?
This is embargoed until ESR10 no longer ships, Jordi. We just shipped the first ESR17. They'll be one more ESR10 release in six weeks. After that, this bug can be discussed in public.