Closed Bug 1149000 (CVE-2015-7185) Opened 5 years ago Closed 5 years ago
Killing the Location bar using fullscreen mode and alert function on another tab (spoofing risk)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0 Build ID: 20150320202338 Steps to reproduce: When you go on the fullscreen mode and an alert() function on another tab, exits the fullscreen mode, the location bar has disappeared. 1 : go on http://www.alternativ-testing.fr/Research/Mozilla/android/firefox37androidspoof/testfs.html and click on the first link (a data: link will be opened on another tab 2 : an alert() will redirect you on the previous tab ( on http://www.alternativ-testing.fr/Research/Mozilla/android/firefox37androidspoof/testfs.html ) , now click on the second link (before 10 seconds) and wait. Actual results: An alert will redirect you on the data: link and exits the fullscreen mode , now the location bar is invisible ! (even if you try to press the back button on android , the location bar has disappeared for always) you ca use now a fake location bar (leading to a Location Bar Spoofing) Expected results: After all these steps, you can use a fake location bar (leading to a Location Bar Spoofing).
I will upload a video of the poc.
Look this video.
I can reproduce the behavior where I am now looking at a spoofed image that appears to be a Google page. However, the entire browser is unresponsive. It does not seem possible to continue to do anything at this point. Can you prove - once the user has arrived at this point - that you can take input from the user and do something? The browser appears to be unusable for me.
i can also use a <form action=http://***><input type='text'><input type='submit' value='submit'></form> for send input content.
(In reply to Matt Wobensmith from comment #3) > I can reproduce the behavior where I am now looking at a spoofed image that > appears to be a Google page. However, the entire browser is unresponsive. It > does not seem possible to continue to do anything at this point. I can confirm on a tablet version of Fennec -- the fake "google search" submit box was fully functional. It would be possible to create a working fake page. It would take work but you could create a working fake location bar and let the user continue to "browse" in the attacker's sandbox. Had to kill the browser to get the real location bar back -- that's a pretty bad usability bug in its own right. A background tab should not be able to steal focus and/or switch tabs on a user. Fennec needs tab-modal dialogs. Mark: who should own this bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Location bar Spoofing using fullscreen mode and alert function on another tab. → Killing the Location bar using fullscreen mode and alert function on another tab (spoofing risk)
(In reply to Daniel Veditz [:dveditz] from comment #6) > A background tab should not be able to steal focus and/or switch tabs on a > user. Fennec needs tab-modal dialogs. Wes has thought about this a while ago. He might be able to point to some places where we can begin a fix. > Mark: who should own this bug? No one yet, but Wes can get an NI to provide some background on the Prompts system. Then we can look at the amount of work to get a fix. NI'ing Chenxia too, just to keep others in the loop.
Note that Android's prompts are app-modal, iirc.
I would probably move this away from tab-modal prompts. I have no idea how we'll do them to be honest. I was hoping we could use DialogFragments at one point... but they don't quite work like that. Needs more experimentation (desktop gave up on this and just did dialogs in XUL). I'm not sure why the urlbar is broken here. Presumably, the alert is causing us to switch tabs, but not undoing any fullscreen flags that were set. Seems like something that needs fixed. In fact, we already try to not allow window.alert to force tabs open  which might have kept this from happening, but we also force switch tabs when we get a DOMWillOpenModalDialog event . That matches desktop behavior so I guess we should keep it. I would look into why that tab switch isn't correctly ending fullscreen mode...  http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/prompts/Prompt.java#130  http://hg.mozilla.org/mozilla-central/annotate/ab0490972e1e/mobile/android/chrome/content/browser.js#l4277
tracking-fennec: --- → ?
mcomella, did you look into this? Do you have thoughts about what we should do?
tracking-fennec: ? → +
I briefly looked into why the toolbar might not reappear when we switch tabs but didn't come to any conclusions (e.g. we don't obviously pin the toolbar hidden when going into fullscreen mode) - I'll take a deeper look soon.
Adding kats as he has been doing some toolbar work recently.
It would be worth retesting on the latest nightly to see if this is still a problem. I did touch various bits of the toolbar pinning/showing/hiding code.
Jordi, as per comment 13, can you check if the latest Nightly still has this issue?
Flags: needinfo?(michael.l.comella) → needinfo?(jordi.chancel)
I already checked that and should have mentioned that this still reproduces on a current nightly. I found that I can see this behavior in the wild by finding an embedded YouTube video start playback, full screen the video, tap the YouTube button. You should be in a similar state as this report.
This youtube video is unrepertoried , only user which know the URL of this youtube video can view it. And i have never given the url of this video , only the CC'list in this bug report can view this video.
(In reply to Kevin Brosnan [:kbrosnan] from comment #15) > I already checked that and should have mentioned that this still reproduces > on a current nightly. I found that I can see this behavior in the wild by > finding an embedded YouTube video start playback, full screen the video, tap > the YouTube button. You should be in a similar state as this report. Yes i have also previously found this possibility (more or less similare) which used the flash fullscreen mode , i have a fonctionnal TESTCASE using the fullscreen flash mode with the same result of the actual testcase.
(comment #15) > (In reply to Kevin Brosnan [:kbrosnan] from comment #15) > > I already checked that and should have mentioned that this still reproduces > > on a current nightly. I found that I can see this behavior in the wild by > > finding an embedded YouTube video start playback, full screen the video, tap > > the YouTube button. You should be in a similar state as this report. ------------------------------ (comment #17) > Yes i have also previously found this possibility (more or less similare) > which used the flash fullscreen mode , i have a fonctionnal TESTCASE using > the fullscreen flash mode with the same result of the actual testcase. Do you want that i report this other testcase in another report ?
I don't know.
Flags: needinfo?(kbrosnan) → needinfo?(bugmail.mozilla)
No it sounds like it is the same underlying issue regardless of what mechanism is used to enter fullscreen mode. I'll take a look at this bug in the near future, once I'm done with fixing the Gingerbread breakage from bug 1180295. Parking with me for now.
Assignee: nobody → bugmail.mozilla
The badness happens because all the fullscreen state on the Java side is global rather than per-tab, so if we switch tabs while in fullscreen then trying to exit fullscreen has no effect (the Fullscreen:Exit message gets sent, but calls mozCancelFullScreen on the wrong document at ). My simple solution is to just make sure we exit full screen before we switch tabs, which solves the problem.  http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=84b869138792#1915
Attachment #8654347 - Flags: review?(mark.finkle)
Comment on attachment 8654347 [details] [diff] [review] Patch LGTM
Attachment #8654347 - Flags: review?(mark.finkle) → review+
Comment on attachment 8654347 [details] [diff] [review] Patch [Security approval request comment] How easily could an exploit be constructed based on the patch? - An actual exploit where the attacker spoofs the URL bar is nontrivial to do, but not impossible. Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? - Kinda, yeah. It makes it obvious that it has something to do with switching tabs while in fullscreen mode, and anybody who manages to construct a case where that happens will see that the browser gets stuck in a state where you can't bring up the URL bar. Which older supported branches are affected by this flaw? - Probably all of them If not all supported branches, which bug introduced the flaw? Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? - It's a one line fix that is easy to backport and should be pretty low risk, for all supported branches. How likely is this patch to cause regressions; how much testing does it need? - Unlikely to cause regressions unless there's content that depends on being able to switch tabs while in fullscreen mode. If there is though, we probably would have noticed this before. Some testing would be good to make sure there aren't other similar cases that got missed (i.e. other ways to switch tabs while in fullscreen mode).
Comment on attachment 8654347 [details] [diff] [review] Patch Clearing sec-approval? as sec-moderate bugs don't need sec-approval, just sec-high and sec-critical ones that affect more than trunk.
https://hg.mozilla.org/integration/fx-team/rev/33817a41e2e1 qawanted for verification before I request uplift to all supported branches.
Kevin, do you know who can do some QA on this change? I'd like somebody to verify and make sure I didn't miss any other codepaths for switching tabs while in fullscreen. If all is good I can request uplift for this.
Comment on attachment 8654347 [details] [diff] [review] Patch Approval Request Comment [Feature/regressing bug #]: unknown; it's been around for a while [User impact if declined]: content that forces a tab switch while the user is fullscreened will cause the user to get stuck on the new tab; they will have to kill the browser in order to get out [Describe test coverage new/current, TreeHerder]: none; tested locally and pending QA verification [Risks and why]: pretty low risk; one-line patch [String/UUID change made/needed]: none
Comment on attachment 8654347 [details] [diff] [review] Patch At this point in the 41 cycle (RC week), only bugs which are sec-crit + easy to exploit, severe crash/hangs and major regressions that make the release unusable will be considered. Given that, this is a wontfix for 41.
Attachment #8654347 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Attachment #8654347 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified as fixed on Firefox 42 Beta 1 following the steps and using the test case from comment 0
You need to log in before you can comment on or make changes to this bug.