1762068 - Mixing of cross-origin and ServiceWorker range responses with media element (cross-origin data leak)

Status: RESOLVED DUPLICATE of bug 1735923

(Core :: Audio/Video: Playback, defect, P2)

Description

[Karl Tomlinson (:karlt)]

Gecko does not yet pass on Range headers passed to fetch() (bug 1465074), but a variant of Attack 1 can generate an equivalent response to that of fetch(event.request) by merely not handling the FetchEvent.

Comment 1

[Karl Tomlinson (:karlt)]

A variant of the leak-bytes-as-duration attack is to synthesize the header of a WAV file so that the length of the cross-origin resource is leaked through the duration. (Compare bug 1441153.)

Comment 2

[Karl Tomlinson (:karlt)]

ChannelMediaResource::UpdatePrincipal() does attempt to catch responses from different origins, but GetChannelResultPrincipal() is returning a principal with the (cross-origin) URI of the media element request even when the response is synthesized by the ServiceWorker.

Comment 3

[Karl Tomlinson (:karlt)]

(In reply to Karl Tomlinson (:karlt) from comment #2)

GetChannelResultPrincipal() is returning a principal with the (cross-origin) URI of the media element request even when the response is synthesized by the ServiceWorker.

That behavior relates to nsINetworkInterceptController#startSynthesizedResponse():
"The caller may optionally pass a spec for a URL that this response originates from; an empty string will cause the original intercepted request's URL to be used instead."

This is consistent with step 15 of main fetch (after HTTP fetch):
"If internalResponse’s URL list is empty, then set it to a clone of request’s URL list."

Comment 4

[Karl Tomlinson (:karlt)]

Some things of note in the recent attempt to specify a fix for this through "verify a media response":

1. "if internalResponse's URL is null" is never true because of step 15 in comment 3.
2. The spec allows opaque and CORS same-cross-origin responses (from ServiceWorker fetch()) when they are same origin.
3. The spec allows mixing of content from different-path same-cross-origin URLs. (See bug 1762078 comment 4.)

Items 2 and 3 are not a significant concern until bug 1465074 allows service workers to take advantage of them. Still, I'm not going to attempt to maintain spec behavior for item 2, but will block mixture of CORS and opaque responses.

Comment 5

[Karl Tomlinson (:karlt)]

I'll dupe this to bug 1735923 because that is what pushed us to fix.