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

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

--- Comment #5 from Joe Steele <steele@adobe.com> ---
(In reply to Joe Steele from comment #4)
> (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. 

In case it is not clear, I would recommend adding text describing this
mitigation to the spc rather than removing this feature. The text would be
added to the createSession() procedure between 7.8 and 7.9 and say something
like:
"The application MUST validate that the URL contained in default URL refers to
an expected server."


> 
> 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 15:28:05 UTC