1493899 - Address bar spoof with dynamic address bar

Status: RESOLVED WORKSFORME

(Focus :: General, defect)

Description

[Nikhil]

Attachment: test.html

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce:

1. Setup test.html on a server
2. Click on Goto Gmail button
3. You will see a spoofed page with URL https://www.google.com

Works for me on

1. Android Firefox Focus
2. Android Firefox Rocket





Actual results:

Result of this vulnerability is displaying attacker hosted page with a legit domain for example https://www.google.com in this case.


Expected results:

No Spoof

Comment 1

[Andrew McCreight [:mccr8]]

This test case does a document.write of some giant pile of data, then does a set interval that sets the location to Google. This sounds like something that has been reported before and is expected. Boris, does this sound familiar to you? Thanks.

Comment 2

[Tyson Smith [:tsmith]]

The test case seem to just hang when I tried to reproduce the issue.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This doesn't sound obviously familiar.  I also can't reproduce on desktop.

What _might_ be happening here is that you do the document.write, then start trying to navigate but keep canceling the navigation, so the written content keeps showing.  But if the browser UI is updated before the new navigation has matured (is this where Focus/Rocket come in?) then you could have a situation where the previous page's content is still showing but the new URL is showing.  If so, that's a but in the UI of the relevant browsers....

Comment 4

[Nikhil]

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #3)
> This doesn't sound obviously familiar.  I also can't reproduce on desktop.
> 
> What _might_ be happening here is that you do the document.write, then start
> trying to navigate but keep canceling the navigation, so the written content
> keeps showing.  But if the browser UI is updated before the new navigation
> has matured (is this where Focus/Rocket come in?) then you could have a
> situation where the previous page's content is still showing but the new URL
> is showing.  If so, that's a but in the UI of the relevant browsers....

This hangs a bit when you run in focus, but works perfectly on rocket! and yes it doesn't mean to work on desktop FF

Comment 5

[Chris Peterson [:cpeterson]]

Stefan, this bug might be a security issue for Fenix with a dynamic address bar. Fenix is not affected for now because it has a fixed-position address bar.

Comment 6

[Nikhil]

Hey @chris, is Fenix also under Mozilla bug bounty program now?

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Nikhil from comment #6)

Hey @chris, is Fenix also under Mozilla bug bounty program now?

I don't know. This is a question for Stefan Arentz (Fenix engineering manager), who is already CC'd on this bug.

Comment 8

[David Bolter [:davidb] (NeedInfo me for attention)]

Assigning to Stefan to figure out next steps (and follow up on comment 7).

Comment 9

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Colin, would you mind verifying this bug on both Fenix and Focus?

I'm specially interested to understand whether this bug applies to Fenix or not. Although this bug is filed in the Fenix component here on Bugzilla, it seems to be only reported for Focus and Rocket.

Comment 10

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Max, can your team verify this for Rocket? With Rocket having Focus as a starting point, we can probably collaborate on a good fix?

Comment 11

[Kevin Brosnan [Ex-Mozilla]]

(In reply to Stefan Arentz [:st3fan] from comment #9)

Colin, would you mind verifying this bug on both Fenix and Focus?

I'm specially interested to understand whether this bug applies to Fenix or not. Although this bug is filed in the Fenix component here on Bugzilla, it seems to be only reported for Focus and Rocket.

Chris muddied this bug by moving it from Focus where it was reported. It does not apply to Fenix because we have a fixed address bar. It is something we should keep in mind for enabling the dynamic toolbar. Maybe it should be moved back to Focus and a Fenix issue opened to track not repeating previous problems?

Comment 12

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Colin, it will also be interesting to know whether this bug applies to the GeckoView or WebView version of Focus.

Comment 13

[Kevin Brosnan [Ex-Mozilla]]

For Firefox Lite (Rocket) bug 1491553 exists which is exactly the same as this one. As they are separate products it makes sense to track the issues individually.

Comment 14

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Kevin Brosnan [:kbrosnan] from comment #11)

Maybe it should be moved back to Focus and a Fenix issue opened to track not repeating previous problems?

I moved the bug back to Focus.

Paul's team specifically tested URL bar spoofing on Fenix and this specific case did not come back as an issue afaik - Asking Paul because I think Freddy (who did the tests) is on leave until the end of the month.

Comment 15

[Colin Lee]

On Firefox Focus running GeckoView, the exploit code appears to reload a page in an infinite loop after pressing the Goto Gmail button and does not present any web content. If I slow down the setInterval call, it shows a Gmail login with a fully-qualified URL, but it appears to be the real page loaded and not a spoof (or it would have a spoofed URL as used in the code, https://www.google.com).

On Firefox Focus running WebView, the exploit code loads the site for https://www.google.com and not a Gmail login form. If I slow down the setInterval call, it shows the Gmail homepage with a fully-qualified URL, but it appears to be the real page loaded and not a spoof.

While it's possible there is an exploit here, it does not appear to be working as intended on Firefox Focus.

Comment 16

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

(In reply to Kevin Brosnan [:kbrosnan] from comment #13)

For Firefox Lite (Rocket) bug 1491553 exists which is exactly the same as
this one. As they are separate products it makes sense to track the issues
individually.

I don't think it is clear whether these two bugs are the same.

To me it sounds like this bug is a real url bar spoofing one (showing the wrong URL in the native URL bar) while the one filed in Rocket is a UI spoof (it renders the focus url bar in html).

Can anyone confirm that?

Comment 17

[Colin Lee]

Regarding Fenix, I see the same behavior as Focus GeckoView.

There's confusion about how this spoofing bug works. There's no way a dynamic URL bar is relevant to this bug, since it doesn't appear to fake the UI of the URL bar. The exploit, if it works, appears to function by navigating to an exploit site followed by navigating to the real Google site, but the exploit never intends to actually arrive there.

The hope is that the user will type their username and password into the exploit site and submit it while the exploit code is still looping. However, I haven't actually witnessed the exploit site getting loaded before the looping begins. Nor have I seen the spoof URL appear.

Comment 18

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Stefan Arentz [:st3fan] from comment #14)

(In reply to Kevin Brosnan [:kbrosnan] from comment #11)

Maybe it should be moved back to Focus and a Fenix issue opened to track not repeating previous problems?

I moved the bug back to Focus.

Paul's team specifically tested URL bar spoofing on Fenix and this specific case did not come back as an issue afaik - Asking Paul because I think Freddy (who did the tests) is on leave until the end of the month.

Freddy did do testing here, and I don't believe he found any issues. Testing was mainly focused on previous vectors though so that isnt to say that there might not be a new as yet undiscovered approach. However from my own testing, this bug appears to be invalid for Fenix. The phone just seem to hang in a loop of reloading, with the address bar displaying the page where the test page was loaded. Eventually android killed it (presumably OOM). Which is presumably in line with the assessment in comment 11.

Comment 19

[David Bolter [:davidb] (NeedInfo me for attention)]

(In reply to Colin Lee from comment #15)

On Firefox Focus running GeckoView, the exploit code appears to reload a page in an infinite loop after pressing the Goto Gmail button and does not present any web content. If I slow down the setInterval call, it shows a Gmail login with a fully-qualified URL, but it appears to be the real page loaded and not a spoof (or it would have a spoofed URL as used in the code, https://www.google.com).

On Firefox Focus running WebView, the exploit code loads the site for https://www.google.com and not a Gmail login form. If I slow down the setInterval call, it shows the Gmail homepage with a fully-qualified URL, but it appears to be the real page loaded and not a spoof.

Thanks Colin, while it sounds like a GV user is not exploited I think we want something more like the webview behavior. I'll move this to GV for triage.

(Note fix at https://bugs.chromium.org/p/chromium/issues/detail?id=622183)

(In reply to Stefan Arentz [:st3fan] from comment #10)

Max, can your team verify this for Rocket? With Rocket having Focus as a starting point, we can probably collaborate on a good fix?
There is a separate bug for Rocket and given the WV behavior I think we are good there (per Max).

Comment 20

[David Bolter [:davidb] (NeedInfo me for attention)]

Dan ok to lower sec rating given last few comments?

Comment 21

[Daniel Veditz [:dveditz]]

The addressbar is not implemented by "GeckoView", it is a property of each browser's UI. in theory maybe GV needs to expose navigation events or some such to browsers, but there's no hint that's going on here and per Paul there's been testing. Moving this back to Focus, the original bug report.

Comment 22

[Daniel Veditz [:dveditz]]

Like Colin, I cannot reproduce this in the Focus version I get from the Play Store.