Closed Bug 1293463 (CVE-2017-5395) Opened 8 years ago Closed 8 years ago

Firefox for Android: Location Bar Spoofing Risk - The Location Bar remains hidden when the user manually scrolls down a webpage and another website is loaded during this scroll event

Categories

(Firefox for Android Graveyard :: General, defect)

48 Branch
defect
Not set
normal

Tracking

(fennec+, firefox51 fixed)

VERIFIED FIXED
Firefox 51
Tracking Status
fennec + ---
firefox51 --- fixed

People

(Reporter: jordi.chancel, Assigned: rbarker)

References

()

Details

(Keywords: csectype-spoof, sec-low, Whiteboard: [post-critsmash-triage][adv-main51+])

Attachments

(6 files)

Attached file TestCase1.zip (deleted) —
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160726073904 Steps to reproduce: [A demonstration video will be uploaded to show you the malicious result of this security bug] ----- Step1 : Go to http://www.alternativ-testing.fr/Research/Mozilla/android/~F5g9M-Addressbar-Spoofing-j3U7k~/index-start.html ----- Step2 : Go down into this webpage (the location bar disappears) , during this event a malicious webpage which is slow to load will start its loading without that the Location Bar shows its web address (and the Location Bar remains hidden). (During the slow loading of the malicious website, a link specially crafted can be clicked). <!>Step2 INFO : The loading time of the malicious webpage is 9 seconds when you go on the testcase link ( http://www.alternativ-testing.fr/Research/Mozilla/android/~F5g9M-Addressbar-Spoofing-j3U7k~/index-start.html ) but can be changed by a bigger loading time. (The PHP code of the "redirect-and-sleep().php" can be changed by a bigger or smaller loading time).<!> ----- Step3 : After going down into the webpage "index-start.html", the user can click on the link "https://www.google.fr" (before the loading of the malicious webpage which is 9 seconds ) or wait the loading of the malicious website after the scrolling down. ----- Actual results: A faked Location Bar is shown instead the true location bar which remains hidden. When you go on a webpage specially crafted which uses a slow loading to a malicious webpage/website during you scroll down into this first webpage, the Location Bar disappears (even if another website/webpage is loaded), if an user clicks on a link which hasn't effect (crafted specially to mislead the user which thinks that the link goes on the website indicated or of its choice) the Location Bar is always invisible when the malicious Webpage is loaded and this malicious webpage contains a faked Location Bar leading to a Location Bar URL / SSL Spoofing Risk. Expected results: The Location Bar should reappear and be always visible when another webpage is loaded but it is not the case for this security bug. When a webpage is slowly loaded by another webpage, and even if you go down on this webpage (manually scroll down) and that the Location Bar disappears , The Location Bar should be normally visible when another webpage is loaded. The Location Bar should be always visible when another website or another webpage is loaded.
tracking-fennec: --- → ?
Attached file Video Example1 (deleted) —
This is a demonstration video with two different domains for demonstrate that it is possible to change of domain without that the Location Bar reappeared.
I changed the URL of TESTCASE by the TESTCASE used in the "Video Example2"
Flags: sec-bounty?
A bunch of things have to happen so that this works: * The user has to scroll the page to hide the actual toolbar * A slow load of the next page has to be started before the scrolling happens * The user needs to be tricked into clicking a non-functional link before the slow load has finished (To think the new page was loaded because of the click) * The user has to interact with the fake website in a way that the actual toolbar is not revealed (no scrolling) * (The website/toolbar has to be specifically crafted to work on all devices. The current demo does not really work on a Nexus 6P: The toolbar is tiny. But this doesn't matter for the sake of the demo.) Normally we show the toolbar when a location change is happening. But here the location change is happening instantly (<body onload="">) and the scrolling happens afterwards while the request to load the page is sloooooow. Chrome seems to have the same problem with the exception that they will reveal the toolbar as soon as the user focuses a text input and the keyboard comes up. This makes a lot of sense: As soon as you enter text on a webpage you might want to know on what page you actually are. Apart from that I do not know how we could prevent this, except for showing the toolbar on an actual "new page arrived" event instead of a location changed event (Do we have any event like that? It shouldn't trigger when the page changes dynamically).
(In reply to Sebastian Kaspari (:sebastian) from comment #4) > Chrome seems to have the same problem with the exception that they will > reveal the toolbar as soon as the user focuses a text input and the keyboard > comes up. This makes a lot of sense: As soon as you enter text on a webpage > you might want to know on what page you actually are. I think that makes sense as well. Let's just do that? Sebastian, can you take care of that or should I get Randall to do it?
tracking-fennec: ? → +
Flags: needinfo?(s.kaspari)
The amount of user interaction required - as detailed in comment 4 - dictates a sec-low rating.
Keywords: sec-low
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #5) > (In reply to Sebastian Kaspari (:sebastian) from comment #4) > > Chrome seems to have the same problem with the exception that they will > > reveal the toolbar as soon as the user focuses a text input and the keyboard > > comes up. This makes a lot of sense: As soon as you enter text on a webpage > > you might want to know on what page you actually are. > > I think that makes sense as well. Let's just do that? Sebastian, can you > take care of that or should I get Randall to do it? This would be great. I've a bunch of things to look into and I don't know much about the form and toolbar (the scrolling part) code yet. Randall, do you have time for that?
Flags: needinfo?(s.kaspari) → needinfo?(rbarker)
Assignee: nobody → rbarker
Flags: needinfo?(rbarker)
This patch attempts to show the dynamic toolbar whenever the soft keyboard is shows.
Attachment #8783112 - Flags: review?(s.kaspari)
Attachment #8783112 - Flags: review?(s.kaspari) → review+
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 51
Group: firefox-core-security → core-security-release
This new testcase version (TesCase2) is more convincing to trap an user. Steps: 1) Go to http://www.alternativ-testing.fr/Research/Mozilla/android/~H7G5F-Firefox-Android_Addressbar-Spoofing_using-manually-scroll-down-and-a-slow-redirect-to-malicious-website~/index-step1.html and click on the "ClickMe" link (a new tab is opened with a Google webpage ( https://www.google.com/?[...] ) 2) scroll down manually on this Google webpage (during this scroll event , a slow loading of a malicious webpage is defined after the loading of the Google webpage. Results: The Location Bar is hidden and a fake location bar is showed (instead the real location bar) with a fake SSL indicator and a fake google URL (https://www.google.com). I Upload immediately a a video example to show how this testcase works exactly.
Video Example3 of the new testcase uploaded today which is more convincing.
I changed the URL of the previous TESTCASE used for the last TESTCASE uploaded which is more convincing -> TestCase2 (TestCase more convincing).zip -> https://bugzilla.mozilla.org/attachment.cgi?id=8787514 .
Does this new test case require a new/different fix? If so then we might want to move this to a new bug report.
(In reply to Sebastian Kaspari (:sebastian) from comment #13) > Does this new test case require a new/different fix? If so then we might > want to move this to a new bug report. I think that this new testcase doesn't require a new/different fix but this testcase seems to be a spoofing more convincing than the previous testcases.
Flags: sec-bounty? → sec-bounty+
Jordi, please verify that this bug has been fixed. Thank you.
Flags: qe-verify-
Flags: needinfo?(jordi.chancel)
Whiteboard: [post-critsmash-triage]
This vulnerability is fixed on Firefox Beta 51 for Android, the real Location Bar appears and shows the real address of the malicious webpage/website used when the user want write its Login/Password into the <input type="text" / "password"> on the malicious webpage. This Spoofing is Resolved/Fixed (Tested on Firefox Beta 51 for Android)
Flags: needinfo?(jordi.chancel)
Status: RESOLVED → VERIFIED
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main51+]
Alias: CVE-2017-5395
Depends on: CVE-2017-5452
Attachment #8790361 - Attachment description: jordi.chancel@alternativ-testing.fr,500?,2016-08-08,2016-08-25,2016-09-12,true,,, → jordi.chancel@alternativ-testing.fr,500,2016-08-08,2016-08-25,2016-09-12,true,,,
Group: core-security-release
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: