1217387 - e10s -- Location Bar Spoofing: location bar continues displaying broken resource URI if user tries to navigate to it manually

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[:Gijs (he/him)]

Bug 1189082 fixes this outside of e10s, but it's still broken in e10s. We need to apply the same fix to browser-child.js, it seems.

+++ This bug was initially created as a clone of Bug #1189082 +++

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

Steps to reproduce:

When you are on a malicious webpage which contains a link like : 

wyciwyg://https://www.google.com/  , 

copy this link and make a right click into the location bar and click on the selection :"Past and Go" 

All these steps lead to a Location Bar Spoofing Vulnerbility 

Steps with the testcase :
-1 : copy the URL into the link in the testcase webpage, make a right click into the location bar and click "Past and Go".
-2 : after all these steps , Location Bar is Spoofed.


Actual results:

With the wyciwyg:// protocol it's possible to spoof the location bar by a simple interraction like drag and drop a link into the location bar or copy the link URL and try to go on this URL by a right click into the location bar and a click on "Past and Go".


Expected results:

With the wyciwyg:// protocol it's possible to spoof the location.

code a patch of the "past and go" of an url with the protocol wyciwyg:// don't change the URL of the original webpage can be a possible idea to resolve this vulnerability.

Comment 1

[:Gijs (he/him)]

I'm actually not sure how to do this, because the error handling is currently done on the chrome side, and the error is actually thrown in the content process. I guess we'd need to send a message from the content side back up? That sounds like it might have issues getting out of sync...

Comment 2

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #1)
> I'm actually not sure how to do this, because the error handling is
> currently done on the chrome side, and the error is actually thrown in the
> content process. I guess we'd need to send a message from the content side
> back up? That sounds like it might have issues getting out of sync...

Marco, do you have ideas here?

Comment 3

[Marco Bonardo [:mak]]

(In reply to :Gijs Kruitbosch from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > I'm actually not sure how to do this, because the error handling is
> > currently done on the chrome side, and the error is actually thrown in the
> > content process. I guess we'd need to send a message from the content side
> > back up? That sounds like it might have issues getting out of sync...

sorry, I don't have better ideas. We can pass the url along with the message and compare it before the revert, if you're worried about syncing.

Comment 4

[Jordi Chancel]

Can you add in the title of this bug report ["resource URI scheme spoofing (eg: resource://www.google.com/ )"] because this Location Bar Spoofing vulnerability can be also be used with the "resource:" URI scheme and the version of Firefox with the security patch attached must be tested with this other URI scheme.


Tests which must be done for verified if the patch is valid :

1st TEST : copy the URL address "resource://www.google.com/" and make a right click on the location bar and choose the option "Paste & Go"

2nd TEST : copy the URL address "wyciwyg://www.google.com/" and make a right click on the location bar and choose the option "Paste & Go"

If these two tests don't lead to a URL spoofing into the location bar , This vulnerability is definitely resolved.

Comment 5

[Andrew McCreight [:mccr8]]

Is this still an issue now that pages can't use wyciwyg URLs? I'm not sure about the resource part of it.

Comment 6

[:Gijs (he/him)]

(In reply to Andrew McCreight [:mccr8] from comment #5)

Is this still an issue now that pages can't use wyciwyg URLs? I'm not sure about the resource part of it.

Yeah, I think the resource: part probably continues to apply. Considering the amount of user interaction required and the relatively unconvincing result, I'm not convinced it's all that serious. It might end up being addressed by bug 1510569.

Comment 7

[Drew Willcoxon :adw]

Attachment: POC 2 on 68.9.0esr

With POC 1 in bug 1189082, we now do a search for the wysiwyg link on both 68.9.0esr and 77.0.1.

With POC 2 on 68.9.0esr, we end up with the attached screenshot, which I guess is the spoof? On 77.0.1, nothing happens: the urlbar retains its URL, i.e., the resource URL doesn't appear to be pasted at all, although sometimes there's flickering. I bisected and this commit fixed it: https://hg.mozilla.org/mozilla-central/rev/94663676 That changeset is related to e10s but it's not obvious to me how it fixed it, so I ran the bisect twice and got the same result.

Does anyone object to closing this?

Comment 8

[:Gijs (he/him)]

(In reply to Drew Willcoxon :adw from comment #7)

I bisected and this commit fixed it: https://hg.mozilla.org/mozilla-central/rev/94663676 That changeset is related to e10s but it's not obvious to me how it fixed it, so I ran the bisect twice and got the same result.

The entire push to autoland for that bug : https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=94663676950dbdef63afb4d134b8add076a70b0b

enabled document channel for all protocols, which seems pretty plausible as something that'd fix this, given that it moved handling of most of navigation and loading of content to the parent process. So yes, I think this can be closed.