Bug 193718 – [GStreamer] HLS, DASH, and Smooth Streaming implementations ignore proxy settings

• Status: RESOLVED
• Resolution: FIXED
• Component: Security

[Michael Catanzaro]

When removing the web process's access to network proxy settings, I thought to wonder how HLS could use them if HLS accesses the network in the web process. Answer must be that it has never used our proxy settings. This is a major security bug of the sort that requires a CVE at least, to inform users who may have been affected.

Proper solution is to route the HLS implementation through the network process, so our sandbox can disable the web process's ability to access the network altogether.

If we don't have time for that, we could add a GStreamer-specific way to move the proxy information from the UI process to the web process, and keep it in sync when it changes. (The previous method for sending proxy data to the web process is being removed, because it was unused.)

And if we don't have time for THAT, then I dunno, we need to handle it somehow.

[Radar WebKit Bug Importer]

<rdar://problem/47480760>

[Philippe Normand]

See https://bugs.webkit.org/show_bug.cgi?id=189967#c3

[Philippe Normand]

So what's left to be done for this?

[Michael Catanzaro]

Make sure GStreamer is using the SoupNetworkSession in the NetworkProcess to download stuff. Then nothing more should be required. You've already succeeded at that, right? So we can close this now?

We should also request a CVE, because this is a deanonymization issue.

[Philippe Normand]

(In reply to Michael Catanzaro from comment #4)
> Make sure GStreamer is using the SoupNetworkSession in the NetworkProcess to
> download stuff. 

Looks like it does! A single SoupNetworkSession is created in the NetworkProcess during HLS playback, and souphttpsrc is no longer used for fragments downloading.

> Then nothing more should be required. You've already
> succeeded at that, right? So we can close this now?
> 

I suppose, yes.

> We should also request a CVE, because this is a deanonymization issue.

If you say so :)

[Michael Catanzaro]

I'll handle the CVE request. Is r243197 the commit that fixed this? Please help me find the commit that fixed it. :)

Note: I wrote some recommendations https://trac.webkit.org/wiki/WebKitGTK/MaintenanceTips#CVERequests about when we should request CVEs.

[Philippe Normand]

Yes, r243197, which depends on r243140 and r243058

[Michael Catanzaro]

https://trac.webkit.org/changeset/243197/webkit is the commit that fixed this.