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

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

            Bug ID: 26838
           Summary: Normatively address vulnerabilities related to
                    initData contained in media data
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: hsivonen@hsivonen.fi, mike@w3.org, mkwst@google.com,
                    public-html-media@w3.org, sleevi@google.com

Though not necessary, the EME model assumes that the initData passed to
generateRequest() is the "encrypted" event’s initData, which the UA parsed from
the media data. This presents an attack vector that is not addressed by other
mitigations, including CORS and secure origins (bug 26332).

Specifically, CDMs parse the initData and many CDM implementations are likely
to be a) closed source and b) running with more privileges than the user
agent's renderer. (See also [1].) In addition, most existing DRM
implementations use proprietary, closed, and/or opaque formats (mainly PSSH
boxes), which may not be publicly inspected. They may also use formats, such as
XML, that may require complex parsers in the CDM.


The EME requirement that the "media data [must be] CORS-same-origin" [2] for
the parsed initData to be provided to the application only protects the media
data. It does not protect the user or CDM in any way - an attacker's server
would allow all origins. As a result, malicious media data may end up being
passed to a "trusted" application that will then provide it to the CDM. (This
is especially a concern in the “federated” case.)  This is an even more serious
problem if one were to rely on secure origins to safeguard the user/CDM.

The concern can be broken into the following categories:
1) Non-secure application origin
 1) Network attacker (attack #13 in [3])
 b) User navigates (attack #9 in [3])
2) Application has a secure origin, but:
 a) Not all media data is blocked in the mixed content case (see below),
reducing this case to #1
 b) Media data is retrieved from a third-party server (i.e. the federated case)

1a) This can be prevented by enforcing secure origins (bug 26332).

1b) This may be mitigated by enforcing secure origins (bug 26332), especially
if the user agent requires permissions, but it may also need additional
mitigations (as with 2b).

2a)
Per Mixed Content [4], for applications using HTTPS:
* The .src= case ("Optionally-blockable Content") would allow initData from
anywhere to be provided to the CDM.
* The MSE case would allow initData from any HTTPS origin to be provided to the
CDM.

We could explicitly close the .src mixed content loophole by preventing
initData from being populated in the mixed content case in the same way we
enforce CORS. That would at least address the network attacker case. (In
addition to #13 in [3], it also addresses #14 and #15.)

2b)
That leaves the case where an attacker has an HTTPS server and somehow
convinces the application or user to load media data from that server. This is
probably unlikely for a case like Netflix, but it could happen in a federated
scenario. Also, the lure of elevated access and a vulnerable CDM could be
enough to motivate someone to find an exploit in a content provider's site.

[1] The paragraph starting with "Note: Unsandboxed CDMs..." at
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#security
[2] Step 3 of
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#algorithms-initdata-encountered
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c70
[4] https://w3c.github.io/webappsec/specs/mixedcontent/

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

Received on Wednesday, 17 September 2014 19:50:24 UTC