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

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

Joe Steele <steele@adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steele@adobe.com

--- Comment #3 from Joe Steele <steele@adobe.com> ---
(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? 

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 .

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. 

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.

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

Received on Tuesday, 23 September 2014 14:23:04 UTC