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.

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

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

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.

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.

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

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.

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

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.

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

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.

Track 54+/55+ as sec-high.

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 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+

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.

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.

Track 53+ as security related issue.

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.

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