1227538 - (CVE-2016-5298) "Javascript:" URL scheme can seem secure with a SSL indicator (leading to SSL Spoofing) and the wrong URL indicated can mislead the user about the real URL visited.

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Jordi Chancel]

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

Steps to reproduce:


1) Go to https://www.alternativ-testing.fr/Research/Mozilla/android/Zd7k-JavaScript-URL-Scheme-URL_and_SSL_Spoofing/poc.html

2)Copy the URL of the link into this specialy crafted webpage,

3)Paste this URL into the Location Bar ,

4)And after, Go to this URL.

( You can look the demonstration video that i will uploaded quickly in the attachments for view the exact steps needed and the real severity of this security bug )



Actual results:

The javascript URL has a SSL indicator and the wrong URL indicated can mislead the user about the real URL visited.


Expected results:

A javascript URL should never have a SSL indicator and when a javascript URL malformed is paste and a user try to go on this malformed javascript URL , the web page and the location bar shouldn't be affected by this interaction.

Comment 1

[Jordi Chancel]

Attachment: Video-Example1 Bug 1227538 - Firefox 42 for Android - SSL Spoofing and wrong URL can mislead the user about real URL visited.html

Look this video for view how works this vulnerability 
(steps needed and results).

Comment 2

[Jordi Chancel]

Attachment: screenshot - Bug 1227538.png

You can look this screenshot also.

Comment 3

[Daniel Veditz [:dveditz]]

The javascript bit of this is really not all that convincing ("Paste and Go", the more likely user action, doesn't even work for javascript urls) but Fennec is definitely not acting in accordance with anti-spoofing actions we've taken in desktop: when you start loading some other page you clear the previous site's indicia before you do anything (lest a failure--as happens here--lead to that step being skipped). There are possibly other ways to get into this state. For example, we've had similar problems in the past when the URL returned a 204 or never answered at all.

I'm also dismayed to see the favicon in the URL bar. Not this bug per se, but this bug takes advantage of that fact. It also means an insecure site can use a green lock as a favicon and fool people into thinking they're secure on a http: site (who is going to remember that there ought to be two icons for an actually secure site). This is not new: worrying about spoofed locks was partly behind us killing off the lock in Firefox 3 in favor of an "identity block", and killing off favicons in the Firefox 14 (ish?) site identity redesign after we brought back the lock. https://zeltser.com/padlock-and-favicon-confusion-in-browsers/

Comment 4

[:Margaret Leibovic]

(In reply to Daniel Veditz [:dveditz] from comment #3)
> The javascript bit of this is really not all that convincing ("Paste and
> Go", the more likely user action, doesn't even work for javascript urls) but
> Fennec is definitely not acting in accordance with anti-spoofing actions
> we've taken in desktop: when you start loading some other page you clear the
> previous site's indicia before you do anything (lest a failure--as happens
> here--lead to that step being skipped). There are possibly other ways to get
> into this state. For example, we've had similar problems in the past when
> the URL returned a 204 or never answered at all.
> 
> I'm also dismayed to see the favicon in the URL bar. Not this bug per se,
> but this bug takes advantage of that fact. It also means an insecure site
> can use a green lock as a favicon and fool people into thinking they're
> secure on a http: site (who is going to remember that there ought to be two
> icons for an actually secure site). This is not new: worrying about spoofed
> locks was partly behind us killing off the lock in Firefox 3 in favor of an
> "identity block", and killing off favicons in the Firefox 14 (ish?) site
> identity redesign after we brought back the lock.
> https://zeltser.com/padlock-and-favicon-confusion-in-browsers/

This is bug 1018994, there's a recent discussion happening in there.

Anthony, can we raise the priority of that bug?

Comment 5

[Jordi Chancel]

This bug and bug 1018994 are not the same at all , 
the bug 1018994 use a favicon of a fake SSL indicator for mislead user ,

but in this bug , the JavaScript URL pasted and visited have a real SSL indicator of the malicious previous website visited by the user.

Comment 6

[Daniel Veditz [:dveditz]]

I'm sure Margaret meant to quote only my second paragraph, where I explicitly said "not this bug". Bug 1018994 is not this bug, it was the reference for the broken behavior I described in that paragraph (Thanks for the link, Margaret -- I knew there had to be one but my bugzilla-fu failed me).

My first paragraph describes the problem with _this_ bug in a way that is broader than just the javascript: particulars of your testcase. You happened to trigger the load failure using a javascript: url containing syntax errors, leading to failure to clear the previous favicon/lock state. There may be other load errors that lead to the same effect. I don't find your javascript PoC all that convincing and based only on that I would rate this sec-low. Since I know the failure to clear the lock led to more convincing spoofs on desktop I'm assuming a decent chance of finding similar in Fennec and thus raised the severity on that possibility.

Comment 7

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Having trouble following along in here. But it sounds like I should be diverting my comments to bug 1018994.

Comment 8

[Daniel Veditz [:dveditz]]

Without already-known bug 1018994 the remaining bits here do not rise to the level of the bounty.

When loading a URL fails we have 2 good choices, and the less good behavior we do here.
  0. Do nothing (current behavior): leaves "bad" URL sitting on old content
  1. revert URL to match the contents actually displaying
  2. clear the old content (show an error page)

On slow, bandwidth-constrained Android #2 is problematic, but given how hard it is to type on mobile #1 is an problematic response to a typo. Is there a 4th choice, like an infobar saying the URL is invalid, that would let the user know their URL didn't load without hitting the downsides of our current behavior?

Anyway, we should fix bug 1018994 first.

Comment 9

[:Margaret Leibovic]

Sebastian, can you look at this?

Comment 10

[Sebastian Kaspari (:sebastian; :pocmo)]

yep!

Comment 11

[Sebastian Kaspari (:sebastian; :pocmo)]

We get into this situation because of two things that happen:

1) We set the URL in the URL bar right after the user has entered a new URL (Technically there are two URLs: One that we display and one that the user edits). This is for immediate visual feedback. Otherwise we would show the old URL until we receive an location change event.

2) After entering the "JavaScript URL" from the POC we do not receive a single event from the Gecko/JS. Therefore there's no update (URL, site identity / lock, progress, ...).

So technically we never leave the current site but we display the URL the user just entered (See 1). Note that when you click the URL bar you are going to edit the actual URL again and not the "javascript URL" you just entered.

I'm not sure what the best path forward is here. I've prepared a patch that resets the SiteIdentity state (e.g. the lock) of the tab after entering a new URL. This seems to be what desktop does as well. I also noted that for unknown schemes (foo://bar) we just do nothing as well (desktop seems to perform a search at least) - maybe not the best UX but something for another bug.

Comment 12

[:Margaret Leibovic]

(In reply to Sebastian Kaspari (:sebastian) from comment #11)
> We get into this situation because of two things that happen:
> 
> 1) We set the URL in the URL bar right after the user has entered a new URL
> (Technically there are two URLs: One that we display and one that the user
> edits). This is for immediate visual feedback. Otherwise we would show the
> old URL until we receive an location change event.
> 
> 2) After entering the "JavaScript URL" from the POC we do not receive a
> single event from the Gecko/JS. Therefore there's no update (URL, site
> identity / lock, progress, ...).
> 
> So technically we never leave the current site but we display the URL the
> user just entered (See 1). Note that when you click the URL bar you are
> going to edit the actual URL again and not the "javascript URL" you just
> entered.
> 
> I'm not sure what the best path forward is here. I've prepared a patch that
> resets the SiteIdentity state (e.g. the lock) of the tab after entering a
> new URL. This seems to be what desktop does as well. I also noted that for
> unknown schemes (foo://bar) we just do nothing as well (desktop seems to
> perform a search at least) - maybe not the best UX but something for another
> bug.

I think this sounds like the right call. Alternately, we could also try resetting the URL back to the actual page URL if we failed to load anything. Do we get any sort of error event to indicate that there was a failed attempt to change location? But this would be annoying if you have a typo in what you entered, and you would need to enter it all again.

The good news is it doesn't sound like anything malicious can actually happen to the user here, but we should do our best to make sure people know what page they're actually on.

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #12)
> I think this sounds like the right call. Alternately, we could also try
> resetting the URL back to the actual page URL if we failed to load anything.
> Do we get any sort of error event to indicate that there was a failed
> attempt to change location? But this would be annoying if you have a typo in
> what you entered, and you would need to enter it all again.

We don't receive any events in case of failure here.

However we already reset the URL when editing it again:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/toolbar/BrowserToolbar.java#776

So right now we have already this annoyance:
* Go to example.com
* Edit URL and enter javascript:foobar
* We display javascript:foobar but nothing happens
* Edit URL again. The URL is example.com again.
* Cancel edit: We still display javascript:foo


> The good news is it doesn't sound like anything malicious can actually
> happen to the user here, but we should do our best to make sure people know
> what page they're actually on.

Yeah, it looks like in this situation this is not exploitable.

Comment 14

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: 1227538-reset-site-identity.patch

Comment 15

[Sebastian Kaspari (:sebastian; :pocmo)]

The patch above resets the site identity state if you edit the URL. This seems to be what desktop does as well.

I filed two separate bugs for the things mentioned above:
* Bug 1278581 - Nothing happens after entering URL with unknown protocol like foo://bar
* Bug 1278616 - Editable URL always resets to last *loaded* URL

They both are slightly unrelated and they don't seem to be security relevant so we can't discuss/fix them separately.

Comment 16

[Sebastian Kaspari (:sebastian; :pocmo)]

https://hg.mozilla.org/integration/fx-team/rev/b240666f8af8cd36887c3b312a41045ab8882f88
Bug 1227538 - Reset site identity after entering new URL. r=margaret

Comment 17

[Carsten Book [:Tomcat]]

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

Comment 18

[Matt Wobensmith [:mwobensmith][:matt:]]

Jordi, can you confirm that this has been fixed? Thank you.

Comment 19

[Jordi Chancel]

(In reply to Matt Wobensmith [:mwobensmith][:matt:] from comment #18)
> Jordi, can you confirm that this has been fixed? Thank you.

Yes, tested on the last Firefox Beta version for Android and this has been fixed.

Comment 20

[Paul Silaghi, QA [:pauly]]

Verified fixed on FX 50 based on comment 19.