Bug 1149000 (CVE-2015-7185)

Killing the Location bar using fullscreen mode and alert function on another tab (spoofing risk)

RESOLVED FIXED in Firefox 42

Status

()

defect
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: jordi.chancel, Assigned: kats)

Tracking

(4 keywords)

39 Branch
Firefox 43
ARM
Android
Points:
---
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox41 wontfix, firefox42 verified, firefox43 fixed, fennec+)

Details

(Whiteboard: [adv-main42+], )

Attachments

(3 attachments)

Reporter

Description

4 years ago
Posted file TESTCASE1.html
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).
Reporter

Comment 1

4 years ago
I will upload a video of the poc.
Reporter

Comment 2

4 years ago
Look this video.
Reporter

Updated

4 years ago
OS: Mac OS X → Android
Hardware: x86 → Other
Reporter

Updated

4 years ago
Hardware: Other → ARM
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.
Reporter

Comment 4

4 years ago
yes I can use an input ( write on it and send it content via javascript, do you want a video of demo?) 
i use android 4.4.4.
Reporter

Comment 5

4 years ago
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
Flags: needinfo?(mark.finkle)
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)
Flags: sec-bounty?
(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.
Flags: needinfo?(wjohnston)
Flags: needinfo?(mark.finkle)
Flags: needinfo?(liuche)
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 [1] which might have kept this from happening, but we also force switch tabs when we get a DOMWillOpenModalDialog event [2]. 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...

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/prompts/Prompt.java#130
[2] http://hg.mozilla.org/mozilla-central/annotate/ab0490972e1e/mobile/android/chrome/content/browser.js#l4277
Flags: needinfo?(wjohnston)
Reporter

Updated

4 years ago
Version: Firefox 37 → Firefox 39
tracking-fennec: --- → ?
mcomella, did you look into this? Do you have thoughts about what we should do?
tracking-fennec: ? → +
Flags: needinfo?(michael.l.comella)
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.
Flags: needinfo?(jordi.chancel)
Reporter

Comment 16

4 years ago
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.
Reporter

Comment 17

4 years ago
(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.
Reporter

Comment 18

4 years ago
(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 ?
Flags: needinfo?(kbrosnan)
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
Flags: needinfo?(bugmail.mozilla)
Posted patch PatchSplinter Review
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 [1]). My simple solution is to just make sure we exit full screen before we switch tabs, which solves the problem.

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=84b869138792#1915
Attachment #8654347 - Flags: review?(mark.finkle)
Flags: needinfo?(liuche)
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).
Attachment #8654347 - Flags: sec-approval?
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.
Attachment #8654347 - Flags: sec-approval?
https://hg.mozilla.org/integration/fx-team/rev/33817a41e2e1

qawanted for verification before I request uplift to all supported branches.
Keywords: qawanted
https://hg.mozilla.org/mozilla-central/rev/33817a41e2e1
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43

Updated

4 years ago
Group: core-security → core-security-release
Flags: sec-bounty? → sec-bounty+
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.
Flags: needinfo?(kbrosnan)
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
Attachment #8654347 - Flags: approval-mozilla-beta?
Attachment #8654347 - Flags: approval-mozilla-aurora?
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-
This is a wontfix for 41.
Attachment #8654347 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 32

4 years ago
Verified as fixed on Firefox 42 Beta 1 following the steps and using the test case from comment 0
Whiteboard: [adv-main42+]
Alias: CVE-2015-7185
Flags: needinfo?(kbrosnan)
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.