1222761 - Regression: FF42 cannot access custom protocol in <source>, FF41 can

Status: RESOLVED WORKSFORME

(Core :: DOM: Security, defect)

Description

[Anthony Lieuallen]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20151014143721

Steps to reproduce:

Context: https://github.com/greasemonkey/greasemonkey/issues/2326

Greasemonkey defines a custom protocol ( https://github.com/greasemonkey/greasemonkey/blob/master/modules/scriptProtocol.js ) with the intent that script authors can include various media at install time for easy reference by a predictable URL.

A user has reported that audio loaded with a <source> tag pointed at this custom protocol worked in FF41 but fails in FF42.  See test script as mentioned at above link:  https://dl.dropboxusercontent.com/u/936879/test.user.js

Comment 1

[Boris Zbarsky [:bzbarsky]]

So if I understand the protocol handler source correctly, it just goes ahead and creates a file:// channel, complete with the file:// URI?  Does it set an originalURI on it?  If not, does setting that to the "greasemonkey-script:" URI help?

Chances are this is a regression from bug 1143922.  Christoph, could you take a look, please?

Comment 2

[Christoph Kerschbaumer [:ckerschb]]

Yes, this is definitely caused by Bug 1143922, here is what I found so far:

STR:
* Install GreaseMonkey
* Install https://dl.dropboxusercontent.com/u/936879/test.user.js
* visit: www.youtube.com

In a debug build you'll see:
> [18783] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4: file /home/ckerschb/moz/mc/dom/security/nsContentSecurityManager.cpp, line 61
> [18783] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4: file /home/ckerschb/moz/mc/dom/security/nsContentSecurityManager.cpp, line 419
> [18783] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4: file /home/ckerschb/moz/mc/netwerk/base/nsSecCheckWrapChannel.cpp, line 180
> [18783] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303F4: file /home/ckerschb/moz/mc/dom/html/HTMLMediaElement.cpp, line 1334

which indicates that CheckLoadURIWithPrincipal() fails, see [1]. Here are the important values:

channelURI: file:///home/ckerschb/.mozilla/firefox/kd3icnjx.grease/gm_scripts/test/test.ogg
loadingPrincipal: https://content.googleapis.com/static/proxy.html?jsh=m%3B%2F_%2Fscs%2Fabc-static%2F_%2Fjs%2Fk%3Dgapi.gapi.en.xjOqtrB8Fx8.O%2Fm%3D__features__%2Fam%3DAAQ%2Frt%3Dj%2Fd%3D1%2Frs%3DAItRSTOblpNtoWHpPOhBTtm7mc3TCZFA0g#parent=https%3A%2F%2Fwww.youtube.com&rpctoken=810686204
contentPolicyType: 30 - TYPE_INTERNAL_AUDIO

[1] http://mxr.mozilla.org/mozilla-central/source/dom/security/nsContentSecurityManager.cpp#57

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

What I see there was no CheckLoadURIWithPrincipal() check before we introduced asyncOpen2, see:
https://hg.mozilla.org/mozilla-central/rev/accaecdd989d

Jonas, any suggestions?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

There was definitely a checkLoadURIWithPrincipal call before as well. Had we not had that that would have been a serious security problem.

https://hg.mozilla.org/mozilla-central/rev/accaecdd989d#l1.134

I suspect bz is on the right track. Previously we did a checkLoadURIWithPrincipal check against the URI in the src attribute. Now we call NS_GetFinalChannelURI and do the security check against that. That's probably where the difference lies.

Is the protocol handler forgetting to call SetOriginalURI on the channel? That would be my guess.

Or is the LOAD_REPLACE flag set here for some reason?

Here's what the chrome:// protocol handler does before it returns a channel. Most likely the greasemonkey handler should do the same thing.

http://mxr.mozilla.org/mozilla-central/source/chrome/nsChromeProtocolHandler.cpp#172

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jonas Sicking (:sicking) from comment #4)
> Here's what the chrome:// protocol handler does before it returns a channel.
> Most likely the greasemonkey handler should do the same thing.
> 
> http://mxr.mozilla.org/mozilla-central/source/chrome/nsChromeProtocolHandler.
> cpp#172

Thanks Jonas - clearing my needinfo.

Comment 6

[Anthony Lieuallen]

Confirmed that setting originalURI (in Greasemonkey) resolves this problem.