This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From my reading of the EME draft, it seems that a CDM which can run arbitrary code embedded into the media stream would currently be standard compliant. Furthermore, the stream of the media_element and the message interface from EME provide a bi-directional link between an arbitrary server and a (potentially hijacked) CDM, which runs with the same privileges as the user-agent. This poses a potential thread to the security of the user's system.
(In reply to comment #0) > From my reading of the EME draft, it seems that a CDM which can run > arbitrary code embedded into the media stream would currently be standard > compliant. > > Furthermore, the stream of the media_element and the message interface from > EME provide a bi-directional link between an arbitrary server and a > (potentially hijacked) CDM, which runs with the same privileges as the > user-agent. This poses a potential thread to the security of the user's > system. No for two reasons: (1) code is not embedded in a media stream; (2) the function of the CDM is not to execute code (whether embedded in the stream or not), but to decrypt media content from the media stream; What specific language in the specification makes you think it does either of these?
(In reply to comment #1) > No for two reasons: > > (1) code is not embedded in a media stream; > (2) the function of the CDM is not to execute code (whether embedded in the > stream or not), but to decrypt media content from the media stream; > > What specific language in the specification makes you think it does either > of these? I fail to see how the CDM is going to decrypt media content WITHOUT running arbitrary code. However, as far as code being run with the same privileges as the user-agent, 1.2.1 does point out: > Implementations may or may not separate the implementations of CDMs and may or may not treat them as separate from the user agent.
(In reply to comment #2) > (In reply to comment #1) > > No for two reasons: > > > > (1) code is not embedded in a media stream; > > (2) the function of the CDM is not to execute code (whether embedded in the > > stream or not), but to decrypt media content from the media stream; > > > > What specific language in the specification makes you think it does either > > of these? > > I fail to see how the CDM is going to decrypt media content WITHOUT running > arbitrary code. A CDM is an implementation detail of a browser. It is implemented by the browser manufacturer either by using code written by the manufacturer or code integrated by the manufacturer. It is not arbitrary and it is not obtained from the media stream. > > However, as far as code being run with the same privileges as the > user-agent, 1.2.1 does point out: > > Implementations may or may not separate the implementations of CDMs and may or may not treat them as separate from the user agent. This simply means that the code that implements a CDM may be directly bound into the browser's binary or it may be a distinct binary linked at run time (like a device driver). How a specific browser manufacturer decides to integrate a CDM, and which CDMs are integrated (either in a bound or unbound fashion) is up to the manufacturer. The EME specification doesn't care either way. So, as you can see, this is not a case of running arbitrary code, since the browser manufacturer has complete control over what code they choose to integrate. Note that it may be the case in certain CDMs that the CDM's code and execution is delegated to the platform or even to a special hardware processor where the details of the platform/hardware implementation aren't available to the browser manufacturer. However, this is no different from a browser manufacturer making use of other platform APIs (like device drivers) for which the browser doesn't have code access. In other words, in these cases, the browser manufacturer effectively "trusts" the platform code to perform some advertised function (like decrypting a block of data). Since your response indicates that your original filing of this bug was based on a misunderstanding of the spec, I am moving this bug from RESOLVED/NEEDSINFO to RESOLVED/INVALID. If you would like further action, you need to propose a specific change to the specification as written.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > No for two reasons: > > > > > > (1) code is not embedded in a media stream; > > > (2) the function of the CDM is not to execute code (whether embedded in the > > > stream or not), but to decrypt media content from the media stream; > > > > > > What specific language in the specification makes you think it does either > > > of these? > > The absence of specific language which indicates that code shall not be embedded into the media stream. And second the absence of specific language which indicates that the function of the CDM is not to execute code. So to ask directly: Assume a CDM that receives a executable as part of the initialization data, this seems to be covered by "opaque Key System-specific collection of data." (Section 1.2.4) The CDM then runs the executable and provides the standardized interface between the user-agent and the downloaded code. Is this standard compliant, and if not, why not? > [...] > How a specific browser manufacturer decides to integrate a CDM, and which > CDMs are integrated (either in a bound or unbound fashion) is up to the > manufacturer. The EME specification doesn't care either way. > > So, as you can see, this is not a case of running arbitrary code, since the > browser manufacturer has complete control over what code they choose to > integrate. > So you are relegating all security concerns to the browser manufacturer? > Note that it may be the case in certain CDMs that the CDM's code and > execution is delegated to the platform or even to a special hardware > processor where the details of the platform/hardware implementation aren't > available to the browser manufacturer. However, this is no different from a > browser manufacturer making use of other platform APIs (like device drivers) > for which the browser doesn't have code access. In other words, in these > cases, the browser manufacturer effectively "trusts" the platform code to > perform some advertised function (like decrypting a block of data). > > Since your response indicates that your original filing of this bug was > based on a misunderstanding of the spec, I am moving this bug from > RESOLVED/NEEDSINFO to RESOLVED/INVALID. If you would like further action, > you need to propose a specific change to the specification as written. Please note, that this is my first response. I would suggest to specify: 1. A CDM shall not be able to run arbitrary code. 2. A section "Security considerations" which details some of the potential pitfalls of EME CDMs. Similar to section 5 of the web crypto api draft [1]. For this I would suggest to specifically mention, that CDMs are able to communicate with a server and therefore should be sandboxed. [1] http://www.w3.org/TR/WebCryptoAPI/
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > No for two reasons: > > > > > > > > (1) code is not embedded in a media stream; > > > > (2) the function of the CDM is not to execute code (whether embedded in the > > > > stream or not), but to decrypt media content from the media stream; > > > > > > > > What specific language in the specification makes you think it does either > > > > of these? > > > > > The absence of specific language which indicates that code shall not be > embedded into the media stream. And second the absence of specific language > which indicates that the function of the CDM is not to execute code. Why should this be prohibited? It may be that some media format embeds data or that the initialization data contains data that may be interpreted by a CDM. > > So to ask directly: Assume a CDM that receives a executable as part of the > initialization data, this seems to be covered by "opaque Key System-specific > collection of data." (Section 1.2.4) The CDM then runs the executable and > provides the standardized interface between the user-agent and the > downloaded code. > Is this standard compliant, and if not, why not? Yes. Initialization data is key system specific. No restrictions are placed on its interpretation. > > > [...] > > How a specific browser manufacturer decides to integrate a CDM, and which > > CDMs are integrated (either in a bound or unbound fashion) is up to the > > manufacturer. The EME specification doesn't care either way. > > > > So, as you can see, this is not a case of running arbitrary code, since the > > browser manufacturer has complete control over what code they choose to > > integrate. > > > > So you are relegating all security concerns to the browser manufacturer? EME does not define a system for executing code. CDMs are an implementation detail of browser product packaging choices. Why should EME place any constraints on the manufacturer? If the manufacturer wants to ship an insecure product, that's their responsibility, and potential liability. > > > > Note that it may be the case in certain CDMs that the CDM's code and > > execution is delegated to the platform or even to a special hardware > > processor where the details of the platform/hardware implementation aren't > > available to the browser manufacturer. However, this is no different from a > > browser manufacturer making use of other platform APIs (like device drivers) > > for which the browser doesn't have code access. In other words, in these > > cases, the browser manufacturer effectively "trusts" the platform code to > > perform some advertised function (like decrypting a block of data). > > > > > Since your response indicates that your original filing of this bug was > > based on a misunderstanding of the spec, I am moving this bug from > > RESOLVED/NEEDSINFO to RESOLVED/INVALID. If you would like further action, > > you need to propose a specific change to the specification as written. > > Please note, that this is my first response. > > I would suggest to specify: > 1. A CDM shall not be able to run arbitrary code. There is no cause for such a constraint. A CDM is an implementation detail not defined or circumscribed by EME. > 2. A section "Security considerations" which details some of the potential > pitfalls of EME CDMs. Similar to section 5 of the web crypto api draft [1]. > For this I would suggest to specifically mention, that CDMs are able to > communicate with a server and therefore should be sandboxed. CDMs are part of the browser implementation. If a browser implementer wants to support a CDM that communicates directly with a server, that downloads code and executes it, etc., then that is an issue for the browser manufacturer and CDM vendor. It isn't an EME specification issue. EME does not define the CDM to browser interface (if there is one), and does not define CDM behavior other than as an abstract information flow model as indicated in the spec. Any EME implementation is free to implement this model as they see fit. > > [1] http://www.w3.org/TR/WebCryptoAPI/
I have created a new issue 2 [1], addressing the need to provide an informative section on security considerations, perhaps drawing on the text of the same section in the draft WebCrypto ED [2]. I think it is reasonable to address the issue of the possibility of active content. As such, I am reopening this bug, and changing its title to reflect the underlying issue. [1] https://www.w3.org/html/wg/media/track/issues/2 [2] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security
(In reply to comment #5) > Yes. Initialization data is key system specific. No restrictions are placed > on its interpretation. Quick correction: "Initialization Data is a generic term for container-specific data" [1]. ISO CENC happens to allow key system-specific data in the form of PSSH boxes, which are part of the Initialization Data for ISO CENC streams. As with all media data, UAs and CDMs should take care when parsing and handling Initialization Data. [1] https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#initialization-data
(In reply to comment #7) > ISO CENC happens to allow key system-specific > data in the form of PSSH boxes, which are part of the Initialization Data > for ISO CENC streams. What do the key systems use the data from PSSH boxes for? Previously asked: http://lists.w3.org/Archives/Public/public-html-media/2013May/0025.html
(In reply to comment #6) > I have created a new issue 2 [1], addressing the need to provide an > informative section on security considerations, perhaps drawing on the text > of the same section in the draft WebCrypto ED [2]. > > I think it is reasonable to address the issue of the possibility of active > content. > > As such, I am reopening this bug, and changing its title to reflect the > underlying issue. > > [1] https://www.w3.org/html/wg/media/track/issues/2 > [2] > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#security The issue Glenn created has been replace with bug 22909: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909 /paulc
(In reply to comment #8) > (In reply to comment #7) > > ISO CENC happens to allow key system-specific > > data in the form of PSSH boxes, which are part of the Initialization Data > > for ISO CENC streams. > > What do the key systems use the data from PSSH boxes for? > > Previously asked: > http://lists.w3.org/Archives/Public/public-html-media/2013May/0025.html For future reference, there was some discussion of this starting at https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c16 (In reply to comment #9) > The issue Glenn created has been replace with bug 22909: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909 > > /paulc There is now discussion of this specific issues in the above bug.
We should address this as part of the Security Considerations section. There is already discussion of proposed text starting at https://www.w3.org/Bugs/Public/show_bug.cgi?id=22909#c2. *** This bug has been marked as a duplicate of bug 22909 ***