1344517 - (CVE-2017-5452) Firefox for Android: Location Bar Spoofing Risk - The Location Bar remains hidden using scroll event and another website is loaded during this scroll event (Patch for Bug 1293463 doesn't prevent completely Location Bar Spoofing risks)

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

I noticed that the patch for Bug 1293463 does not prevent all Location Bar Spoofing risks because this patch consists to show the real location bar only when the user clicks on a HTML editable tag (<input type=text> ; <input type=password> ; <textarea>).

The essential problem of patch for Bug 1293463 is that the fake location bar continues to replace the real location bar.

Multiple websites, especially the bank websites allowing access to users' bank accounts using a numeric keypad or a web virtual keyboard to write its user credentials (customer-ID and Password).

So, a click on an input tag isn't used by these bank websites (leading to the fake location bar continue to be displayed and the real location bar remains hidden during the writing of user credentials by a numeric keypad or a web virtual keyboard).

NOTE: it's also possible to use fake Android Keyboard to write user credentials needed into a fake <input> tag.

Steps:

Step 1: Go to http://www.alternativ-testing.fr/Research/Mozilla/android/~h5fh85f9j03ftrK9-Location%20Bar%20Spoofing%20with%20scroll%20event%20and%20another%20webpage%20with%20a%20long%20time%20for%20loading~/index-start-1.html and click on the link (a Google search webpage will be opened into a new tab)


Step 2: Scroll down into this webpage (the location bar disappears) , during this scroll event a malicious webpage will load slowly without that the real Location Bar appears leading to Location Bar Spoofing risks (The real Location Bar remains hidden and a fake location bar will replace this real Location Bar). 
 

<!>Step2 INFO : The loading time of the malicious webpage is 9 seconds when you go on the Google search webpage but this loading time can be changed by a bigger loading time. (The PHP code of "redirect-and-sleep().php" can be changed by a bigger or smaller loading time).<!>

Info about the malicious webpage: The malicious webpage, a numeric keypad should be used to write the Customer ID and the Password (like it is used on the login webpage in a bank website.



Actual results:

The fake location bar continue to be displayed and the real location bar remains hidden during the writing of user credentials by a numeric keypad or a web virtual keyboard.

The Location Bar remains hidden when the malicious webpage is loaded and this malicious webpage contains a fake Location Bar leading to a Location Bar URL / SSL Spoofing Risk.



Expected results:

The Location Bar should reappear when another webpage is loaded.

When the user scroll down into a first webpage and a 2nd webpage/website is loaded during this scroll event, the real location bar should reappear when the 2nd webpage is completely loaded.

Solution: The Location Bar should be always visible when another webpage is completely loaded.

Comment 1

[:Gijs (he/him)]

Moving over to android... Randall, can you take a look as you wrote the fix in bug 1293463?

Comment 2

[Jordi Chancel]

Attachment: Video Example1.html

You can look this Video Example to understand the steps required to exploit this Location Bar Spoofing Risk.

Comment 3

[Randall Barker [:rbarker]]

Attachment: 0001-Bug-1344517-Keep-dynamic-toolbar-visible-while-page-is-loading-r-kats-17030611-d9cf452bebd9.patch

Comment 4

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

Comment on attachment 8844122 [details] [diff] [review]
0001-Bug-1344517-Keep-dynamic-toolbar-visible-while-page-is-loading-r-kats-17030611-d9cf452bebd9.patch

Review of attachment 8844122 [details] [diff] [review]:
-----------------------------------------------------------------

Patch looks fine to me, I didn't check to see if it closes all the gaps that result in the spoofing risk.

Comment 5

[Randall Barker [:rbarker]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2c56ed1d36ee7f99809fd609bdfc19a552acb29c

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e990ae64c2a3

Given that this affects older branches, this really shouldn't have landed without a sec rating and sec approval (if needed). Can you please help give this a rating and retroactively request sec-approval if it's high/crit?
https://wiki.mozilla.org/Security/Bug_Approval_Process

Also, please request Aurora/Beta approval on this when you get a chance.

Comment 7

[Randall Barker [:rbarker]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
> https://hg.mozilla.org/mozilla-central/rev/e990ae64c2a3
> 
> Given that this affects older branches, this really shouldn't have landed
> without a sec rating and sec approval (if needed). Can you please help give
> this a rating and retroactively request sec-approval if it's high/crit?
> https://wiki.mozilla.org/Security/Bug_Approval_Process
> 
> Also, please request Aurora/Beta approval on this when you get a chance.

Sorry, I guess I blew it. I guess some one else did all that on the first one I fixed since I was unaware of the proper procedures.

Comment 8

[:Gijs (he/him)]

I don't think this is sec-high. The previous bug that this is effectively a clone of was sec-low. This is also a spoof, and it's easily discovered (just scroll) so I just don't think it warrants sec-high. I've also never seen this "custom keypad" thing before in my life, so I would expect users to be suspicious. Pinging Al to confirm and/or get this sec-triaged.

If we do think this is sec-high or sec-crit, then Randall, you'd want to go to https://bugzilla.mozilla.org/attachment.cgi?id=8844122&action=edit, set the sec-approval flag to '?' and then fill out the form text indicating what the risks are and where this needs uplift.

Comment 9

[:Gijs (he/him)]

(tbh, you probably want to request approval for beta/aurora anyway, once you're confident this doesn't introduce new regressions. Depending on the security severity, you might also want to ask for esr52 uplift.)

Comment 10

[Randall Barker [:rbarker]]

Okay, I asked :snorp and he told me to put it at sec-high. I'm mostly just fumbling around trying to figure out the correct procedure since I've never really had to deal with a security bug before. I'm testing patches for aurora and beta right now. Compiling takes time.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

FWIW, we don't ship Android releases off ESR52, so I don't think we need to worry about that.

Comment 12

[Randall Barker [:rbarker]]

Comment on attachment 8844122 [details] [diff] [review]
0001-Bug-1344517-Keep-dynamic-toolbar-visible-while-page-is-loading-r-kats-17030611-d9cf452bebd9.patch

Approval Request Comment
[Feature/Bug causing the regression]: Dynamic Toolbar v2
[User impact if declined]: The spoofing and described in the bug report would be possible.
[Is this code covered by automated tests?]:no
[Has the fix been verified in Nightly?]:no
[Needs manual test from QE? If yes, steps to reproduce]: 
[List of other uplifts needed for the feature/fix]:none
[Is the change risky?]:no
[Why is the change risky/not risky?]:It is fairly simple patch that just keeps the dynamic toolbar pinned while the page is loading
[String changes made/needed]:none

[Security approval request comment]
How easily could an exploit be constructed based on the patch? Not sure, based on the description in the report it isn't too difficult.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem? Not that I know of.

Which older supported branches are affected by this flaw? it is in release.

If not all supported branches, which bug introduced the flaw? The dynamic toolbar v2 introduced the bug I believe.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be? I was able to cleanly apply the patch to aurora and beta.

How likely is this patch to cause regressions; how much testing does it need? It is always possible when dealing with fennec UI. But the patch is pretty simple.

Comment 13

[Gerry Chang [:gchang]]

Track 54+/55+ as sec-high.

Comment 14

[Gerry Chang [:gchang]]

Comment on attachment 8844122 [details] [diff] [review]
0001-Bug-1344517-Keep-dynamic-toolbar-visible-while-page-is-loading-r-kats-17030611-d9cf452bebd9.patch

Fix a sec-high. Aurora54+.

Comment 15

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/387bb50158f3

Comment 16

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

Comment on attachment 8844122 [details] [diff] [review]
0001-Bug-1344517-Keep-dynamic-toolbar-visible-while-page-is-loading-r-kats-17030611-d9cf452bebd9.patch

Sec-high, Beta53+

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/1a099492211c

Comment 18

[Daniel Veditz [:dveditz]]

This looks way more convincing in the video than it is in real life. Relies on abruptly yanking the user to a new site, that yet somehow convinces the user that's what they meant to do. And if you interact with the page and scroll down the real location bar shows up. Lowering the severity, but it's clever and we're awarding a small bounty.

Comment 21

[Sorina Florean [:sflorean]]

Tested on build Fennec 53 Beta 2 with:
- Lenovo A536 (Android 4.4.2);
- Motorola Nexus 6 (Android 7.0).

Following the steps from description, the real URL was displayed when the 2nd web-page was completely loaded. So mark status53: verified.

Comment 22

[Gerry Chang [:gchang]]

Track 53+ as security related issue.

Comment 23

[Randall Barker [:rbarker]]

Some one filed a bug requesting this fix be undone. Since this bug is still hidden, what should I state a the reason we wontfix it? See Bug 1402034.

Comment 24

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

I suspect Dan can open this bug now since it was fixed in 53.