[Bug 26838] Normatively address vulnerabilities related to initData contained in media data

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

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Whiteboard|                            |Security

--- Comment #4 from David Dorwin <ddorwin@google.com> ---
(In reply to Joe Steele from comment #3)
> (In reply to David Dorwin from comment #1)
> > Potential mitigations:
> > 1) Treat Optionally-blockable [mixed] Content media data as not
> > CORS-same-origin for the purposes of determining ([2] above) whether to
> > provide initData in the "encrypted" event.
> > 2) Update the generateRequest() algorithm to have the user agent validate
> > and/or sanitize (possibly by pre-parsing and sanitizing) the |initData| and
> > pass a verified/sanitized version to the CDM.
> > 
> > I think #1 is reasonable (regardless of the outcome of bug 26332). This
> > simply brings .src= media data to the same level as MSE media data. The
> > Optionally-blockable Content category only exists to avoid breaking existing
> > web pages, which is not a concern for EME. As noted above, this addresses
> > (network-based) attacks #13, #14, and #15 in [3] above.
> > 
> > #2 is consistent with the security considerations in [1] above and good
> > practices for passing "user data" across security boundaries. As noted in
> > [3] above, this is "[analogous] to browsers validating WebGL shaders before
> > passing them to a shader compiler whose bugs aren't under the control of the
> > browser vendor."
> 
> Can you detail more how you would see this working? 

As discussed in the telecon today, there is no normative text about *how* to
validate and/or sanitize, but there are non-normative guidelines about possible
ways to accomplish this.
> 
> Here are some roadblocks I see to this:
> 
> 1) The PSSH formats are often proprietary and confidential. I can imagine
> the documentation being made available to the UA implementer but I am not
> sure how validation would be possible for UAs which are open source (or
> mostly open source) without revealing those formats .

This is not ideal and also makes it difficult to package content. User agents
should consider this when considering whether to support a CDM.

> 2) The initData is often encrypted. It seems unlikely to me that those keys
> would be provided to the UA other than in the context of the CDM itself.
> Passing the encrypted data to the CDM for decryption prior to "cleaning"
> seems like it defeats the purpose of the cleaning. 

It did not sound like there was a concrete scenario of the entire PSSH Data box
being encrypted. (The hypothetical scenarios discuss would be better solved in
other ways, such as encryption in transit.) Thus, the structure and many of the
fields can still be validated.

> 3) The initData is often signed. It is likely that modifications to the
> initData (e.g. removing data perceived as "bad") would invalidate signatures
> on the initData.

This prevents sanitizing or parsing and regenerating, but many other types of
validation can be performed.

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

Received on Wednesday, 24 September 2014 00:08:09 UTC