1149000 - (CVE-2015-7185) Killing the Location bar using fullscreen mode and alert function on another tab (spoofing risk)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jordi Chancel]

Attachment: 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).

Comment 1

[Jordi Chancel]

I will upload a video of the poc.

Comment 2

[Jordi Chancel]

Attachment: Video-Example n°1.html

Look this video.

Comment 3

[Matt Wobensmith [:mwobensmith][:matt:]]

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.

Comment 4

[Jordi Chancel]

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.

Comment 5

[Jordi Chancel]

i can also use a <form action=http://***><input type='text'><input type='submit' value='submit'></form> for send input content.

Comment 6

[Daniel Veditz [:dveditz]]

(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?

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(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.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Note that Android's prompts are app-modal, iirc.

Comment 9

[Wesley Johnston (:wesj)]

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

Comment 10

[:Margaret Leibovic]

mcomella, did you look into this? Do you have thoughts about what we should do?

Comment 11

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

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.

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

Adding kats as he has been doing some toolbar work recently.

Comment 13

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 14

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Jordi, as per comment 13, can you check if the latest Nightly still has this issue?

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

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 16

[Jordi Chancel]

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.

Comment 17

[Jordi Chancel]

(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 18

[Jordi Chancel]

(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 ?

Comment 19

[Kevin Brosnan [Ex-Mozilla]]

I don't know.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 21

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

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

Comment 22

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 8654347 [details] [diff] [review]
Patch

LGTM

Comment 23

[Kartikaya Gupta (email:[e-mail])]

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 24

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 25

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/fx-team/rev/33817a41e2e1

qawanted for verification before I request uplift to all supported branches.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/33817a41e2e1

Comment 27

[Kartikaya Gupta (email:[e-mail])]

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 28

[Kartikaya Gupta (email:[e-mail])]

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 29

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

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.

Comment 30

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

This is a wontfix for 41.

Comment 31

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/11d1409af756

Comment 32

[u421692]

Verified as fixed on Firefox 42 Beta 1 following the steps and using the test case from comment 0