1161367 - window.ScrollTo can delete the location Bar into Firefox OS 1.3 (can be used for URL/SSL Spoofing and ClickJacking Attacks)

Status: RESOLVED DUPLICATE of bug 836610

(Firefox OS Graveyard :: General, defect)

Description

[Jordi Chancel]

Attachment: Test1 Firefox OS Location Bar Deletion.html

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

Steps to reproduce:

On Firefox OS 1.3 in the web-browser Mozilla Firefox , when the JavaScript Function window.ScrollTo() is used , it can delete the location bar for Spoof the URL and SSL into a fake Location Bar.

-1 : Go to http://www.alternativ-testing.fr//Research/firefoxOS/5er64g97b9f45k4iu8-testspoofing-78dfsjklqs51gh65/testfirefoxos.html
-2 : Click on the button "ClickMe to delete the Location Bar"



Actual results:

The Location Bar is deleted and can be replaced by a fake Location Bar for make a Spoofing Attack.

The JavaScript Function window.ScrollTo can be automated when you go to a web page specialy crafted and lead to a spoofing without interraction of the user.


Expected results:

The JavaScript Function window.ScrollTo can be automated when you go to a web page specialy crafted and lead to a spoofing without interraction of the user.

Comment 1

[Daniel Veditz [:dveditz]]

Paul: can you take a stab at rating this one?

Comment 2

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

So this is actually by design. Basically as you scroll down the page, the address bar is hidden to give the content more screen real-estate. It is unhidden again by scrolling back to the top. (You can actually  see this in the attached example - just scroll to the top of the page and the address bar comes back).

In theory you might able trick the user by quickly navigating to a certain scroll position, but short of completely improving the address bar (which we did in later versions) We could improve the usability by reshowing the address bar as soon as the user starts to scrolling upwards, rather than waiting till they get to the top. But this UI has been deprecated by the rocketbar in later versions. So there isn't really anything to do here I think.

The impact is that this behavior might lend credeibility to a phishing attack. But I'm not sure that this bug makes the phishing attacks much more likely to succeed. So I would say this is wont-fix.

Comment 3

[Jordi Chancel]

(In reply to Paul Theriault [:pauljt] from comment #2)
>
>
> It is
> unhidden again by scrolling back to the top. (You can actually  see this in
> the attached example - just scroll to the top of the page and the address
> bar comes back).
>

if i find a way to render impossible that the location bar reappear , (i think know how to do this) , the sec-severity  can be redefined?

and i don't understand what this vuln is defined like sec-low because https://bugzilla.mozilla.org/show_bug.cgi?id=960146 is defined like moderate and have exactly the same impact.

can say me why?

Thanks

Comment 4

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

(In reply to Jordi Chancel from comment #3)
> (In reply to Paul Theriault [:pauljt] from comment #2)
> >
> >
> > It is
> > unhidden again by scrolling back to the top. (You can actually  see this in
> > the attached example - just scroll to the top of the page and the address
> > bar comes back).
> >
> 
> if i find a way to render impossible that the location bar reappear , (i
> think know how to do this) , the sec-severity  can be redefined?

Sure, I was rating this bug on the information provided in comment one. If there was a more persistent attack, say completely DoSing the address bar, maybe we might consider this sec-moderate. But it probably wouldn't change the resolution of this bug. As far as I can tell, this bug affects 1.3 only, and in 2.0 we added a system-wide navigation feature called "the rocketbar" which doesn't have this issue. Another feature added in later versions is the URL being shown in the task manager.


> 
> and i don't understand what this vuln is defined like sec-low because
> https://bugzilla.mozilla.org/show_bug.cgi?id=960146 is defined like moderate
> and have exactly the same impact.
> 
> can say me why?

I can't speak for the choice of rating in 960146. I rated this low, as I said in Comment 2, it merely lends credibility to a phishing attack. Note that the "address bar" doesn't actually shown the address, it shows the page title (and therefore, whatever the page owner wants to display). If you want to see the address you have to tap the address bar, which reveals the page address (which I would concede is spoofable to some extent with your attack). Also note that in Firefox OS, other important browser chrome, such as the back button and the favorite button is not in the top bar, but instead location beneath the bottom of the page, and not affected by this attack. For example if you bookmark the page, it will show you the real url of the page.  

Just to be clear - I'm not marking this a "wont-fix" because it not an important bug to fix. Regardless or rating this is not ideal behavior. However the fix for this are the improvements that we added to later versions.

Comment 5

[Jordi Chancel]

(In reply to Paul Theriault [:pauljt] from comment #4)
> (In reply to Jordi Chancel from comment #3)
> > (In reply to Paul Theriault [:pauljt] from comment #2)
>
>
> > can say me why?
> 
> I can't speak for the choice of rating in 960146. I rated this low, as I
> said in Comment 2, it merely lends credibility to a phishing attack. Note
> that the "address bar" doesn't actually shown the address, it shows the page
> title (and therefore, whatever the page owner wants to display). If you want
> to see the address you have to tap the address bar, which reveals the page
> address (which I would concede is spoofable to some extent with your
> attack). Also note that in Firefox OS, other important browser chrome, such
> as the back button and the favorite button is not in the top bar, but
> instead location beneath the bottom of the page, and not affected by this
> attack. For example if you bookmark the page, it will show you the real url
> of the page.  
> 

Just some answer at what you say :

in the address bar the SSL is showed , so we can spoof the SSL statut, and when you say :
"Note that the "address bar" doesn't actually shown the address, it shows the page title (and therefore, whatever the page owner wants to display). If you want to see the address you have to tap the address bar, which reveals the page address (which I would concede is spoofable to some extent with your attack)."

With this attack we can code a fake URL showing with a click on the fake address bar ,and, it will have exactly the same content as the showing of the address like a real clicking on the real address bar.

So, all you have described can be reproduce with a fake Address Bar,

and when you touch the screen the event touchstart is automaticaly used , and if you define the scrollto JS function with this even , when you touch the screen , the scrolling will automaticly disabled the re-showing of the address bar. 
(if you want a testcase i can code it and send-it on this bug report or on a new report).

Do you agree with me at what i answer on you last comment?

Comment 6

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

> Just some answer at what you say :
> 
> in the address bar the SSL is showed , so we can spoof the SSL statut, and
> when you say :
> "Note that the "address bar" doesn't actually shown the address, it shows
> the page title (and therefore, whatever the page owner wants to display). If
> you want to see the address you have to tap the address bar, which reveals
> the page address (which I would concede is spoofable to some extent with
> your attack)."
> 
> With this attack we can code a fake URL showing with a click on the fake
> address bar ,and, it will have exactly the same content as the showing of
> the address like a real clicking on the real address bar.
> 
> So, all you have described can be reproduce with a fake Address Bar,
> 
> and when you touch the screen the event touchstart is automaticaly used ,
> and if you define the scrollto JS function with this even , when you touch
> the screen , the scrolling will automaticly disabled the re-showing of the
> address bar. 
> (if you want a testcase i can code it and send-it on this bug report or on a
> new report).
> 
> Do you agree with me at what i answer on you last comment?

No need for a new test case - I understand what you mean and I agree that its possible to mimic the scollbar behavior identically. After all, the browser itself is literally a webpage: https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/browser/index.html

Incidentally, this is why we added the URL to the task manager in later versions. Since the task manager is launched by a long press of the home button, there is no way for a webpage to spoof that interaction (since the page itself loses control of the window when the task manager is launched)

Comment 7

[Jordi Chancel]

(In reply to Paul Theriault [:pauljt] from comment #6)
> 
> No need for a new test case - I understand what you mean and I agree that
> its possible to mimic the scollbar behavior identically. After all, the
> browser itself is literally a webpage:
> https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/browser/index.html
> 
> Incidentally, this is why we added the URL to the task manager in later
> versions. Since the task manager is launched by a long press of the home
> button, there is no way for a webpage to spoof that interaction (since the
> page itself loses control of the window when the task manager is launched)

The task manager launched by the home button can't be spoofed by this spoofing attack?
yes and no , yes because we can create a fake home button which launch a fake task manager (i know than the task manager contains pages URLs and title chosen by the user, but instead, we can make another content which can simulate the task manager with other URLs pages).

And there is no Location Bar Spoofing (without another vulnerability which could steal the data in the task manager) which can do that, a location bar spoofing attack is generally used for steal user credential like login/password/credit card number (...).

So when you say that the task manager can't be spoofed perfectly, i would say that an attacker don't want do that.

And like i have allready said, the bug960146 (https://bugzilla.mozilla.org/show_bug.cgi?id=960146) was defined like moderate and is exactly similare to this vulnerability .

So, can you contact the Mozilla Developper in the CC'list of bug960146 and ask if this vulnerability (which is exactly similare) could be defined like moderate please?


Thanks.

Comment 8

[Jordi Chancel]

I have found a way for disabled the re-showing of the address bar , with ontouchstart and onclick event with scrollto JS function the location bar disappears and can't reappear (i upload the testcase now).

i delete sec-low because like you have said : 
"Sure, I was rating this bug on the information provided in comment one. If there was a more persistent attack, say completely DoSing the address bar, maybe we might consider this sec-moderate."

So, thanks to define this bug like sec-moderate.

Comment 9

[Jordi Chancel]

Attachment: testcase v2 (the location bar can't reappear).html

Comment 10

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

Thanks for the effort here, but as I said above in comment 6, a new test was not needed. As I stated in comment 4, ultimately the rating is irrelevant to the resolution here. The issue here is closed due improving the browser UX in later versions. (in any case browser app is removed in 2.0 onwards). Please do not re-open this bug.

I'd encourage you to refocus your testing efforts on later versions (ideally 2.2 onwards).

Comment 11

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

Actually fixed is probably a more accurate status here.

Comment 12

[Daniel Veditz [:dveditz]]

Oops, sorry Paul.

Comment 13

[Daniel Veditz [:dveditz]]

I guess it wasn't fixed until V2.0, but the problem was known and solutions proposed before v1.2 in bug 835152 (note reference to Fennec behavior in bug 835152 comment 7: the Fennec UI was designed with this kind of spoofing in mind). Bug 836610 talks more explicitly about the ability to permanently hide the real address bar and substitute the attacker's own.

There's also bug 860812 which was confusingly wontfixed, while sounding a lot like bug 835152 which /was/ fixed.

The actual implementation of the Rocketbar behavior was in bug 993346

Comment 14

[Julien Wajsberg [:julienw]]

Current situation is not very good either, as the real URL is hidden when there is a <title> in the page.

Comment 15

[Jordi Chancel]

(In reply to Julien Wajsberg [:julienw] (PTO May 8th -> May 17th) from comment #14)
> Current situation is not very good either, as the real URL is hidden when
> there is a <title> in the page.

read comment 5 please.