[Bug 25920] Remove extraction of default URL from createSession() algorithm

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920

--- Comment #4 from Joe Steele <steele@adobe.com> ---
(In reply to Joe Steele from comment #3)
> (In reply to David Dorwin from comment #2)
> > (In reply to Joe Steele from comment #1)
> > One possible attack:
> > 1) A malicious media resource could either be hosted by a server belonging
> > to the application or an unrelated server. In the latter case, since CORS
> > relies on the target server, a malicious server would just allow all Origin
> > values.
> > 2) If the media data is CORS same origin (either via cross-origin XHR or the
> > crossorigin attribute), the needkey event will include the initData.
> > 3) The application responds to the needkey event by passing the initData to
> > createSession().
> > 4) Without the proposed change, the CDM processes the malicious initData,
> > extracts the default URL and provides it in the message event.
> > 5) If the application supports the default URL model, it sends the request
> > to the malicious URL. Again, the malicious server accepts all Origin values.
> > 
> > I don't think we can keep the default URL steps in the spec as is.
> 
> Ok -- now I understand the issue you are raising. This seems like a concern.
> Let me spend some time thinking about this. I would prefer not to throw the
> baby out with the bath water.

I think the risk here is minimal and can be mitigated against. 

This attack requires tricking the application into loading a compromised
resource, either because one of their servers was compromised or because the
files were compromised during download. If the compromised file is either the
manifest or the application itself, there is no additional exposure. The
attacker could just leak a random nonce. If the attacker was able to modify a
media file on the application providers content delivery server then it gets
more interesting. 

Assuming the attacker can generate valid metadata for this key system, and the
application does not do additional validation of the URL prior to sending, then
the attacker gets a license request. The actual media file and the domain were
known ahead of time. Cookies and auth tokens from the application will not be
included by the UA. So the only interesting information is whatever the CDM
adds to the license request.

Section 7.1.3 deals with the kind of information that might be available to an
attacker in this case. I believe a CDM that is complying with the suggestions
for increasing privacy here will reduce the effective information leakage here
to a single unique identifier tied to that domain.

The obvious mitigation here is that if the application does know which license
servers might be sent to, it could validate that this URL is in that list. That
would block this attack completely. 

A less obvious mitigation is that creation of valid metadata may not be
possible without some type of licensing. This could impose cost and legal
constraints and could further enable identification of bad actors.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 11 June 2014 14:00:22 UTC