[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

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

--- Comment #70 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to David Dorwin from comment #52)
> 7) A non-EME-using site (i.e. no reason to use protected media), ad network,
> etc. uses EME to obtain a "permanent" identifier.

Yeah, it makes sense to separate out the case where an ad network uses EME only
for tracking and not to satisfy licensing requirements for movies / TV series /
music.

Also, I failed to list the concern you pointed towards in comment 36: An
attacker giving maliciously crafted input to a non-sandboxed CDM whose
bugginess level the browser vendor can't control (or even assess) in order to
exploit bugs (buffer overflows and the like in the CDM).

These concerns differ from the previous ones, because they relate to exploiting
bugs in implemenation of the DRM instead of exploiting the design of the Key
System protocol or its key provisisioning practices.

I think it makes sense to break this into eight subcases:

8) A malicious site that manages to get the user to navigate to it without
manipulating network traffic of another site sends maliciously crafted EME
messages to the CDM in order to exploit bugs in the Key System protocol
implementation in the CDM to run shell code.

9) A malicious site that manages to get the user to navigate to it without
manipulating network traffic of another site sends maliciously crafted PSSH
boxes to the CDM in order in order to exploit bugs in the Key System protocol
implementation in the CDM to run shell code.

10) A malicious site that manages to get the user to navigate to it without
manipulating network traffic of another site sends maliciously media data to
the CDM in order to exploit bugs in the decryption code of the CDM (or if the
CDM subsumes more functionality than it logically has to, in code that
processes the media file prior to decryption) to run shell code.

11) A malicious site that manages to get the user to navigate to it without
manipulating network traffic of another site sends maliciously crafted
encrypted media data to the CDM in order to exploit bugs in the post-decryption
decoding (codec) code of the CDM to run shell code.

12) An active network attacker injects EME usage into the traffic of a site to
send maliciously crafted EME messages to the CDM in order to exploit bugs in
the Key System protocol implementation in the CDM to run shell code.

13) An active network attacker injects maliciously crafted PSSH boxes to media
data in order in order to exploit bugs in the Key System protocol
implementation in the CDM to run shell code.

14) An active network attacker injects maliciously crafted encrypted media data
to the CDM in order to exploit bugs in the decryption code of the CDM (or if
the CDM subsumes more functionality than it logically has to, in code that
processes the media file prior to decryption) to run shell code.

15) An active network attacker injects maliciously crafted encrypted media data
to the CDM  in order to exploit bugs in the post-decryption decoding (codec)
code of the CDM to run shell code.

Sandboxing would address all of these, but the issue is what can be done with
unsandboxed platform CDMs that the browser vendor can't control (or even
assess).

Restricting EME to secure origins wouldn't address attacks #8...#11. They could
be addressed by maintaining (possibly by asking the user) a list of origins
that are allowed to use EME because they are trusted not to try to exploit bugs
in the CDM. Attack modifications to bypass the allow-list would basically be
attacks #12...#15, which could then be addressed by requiring secure origins.

Restricting EME to secure origins and blocking mixed-content XHR and Web
Sockets would address attack #12. It would also address attack #13 when
initialization data is carried outside the media files. However, unless passive
mixed-content is blocked, too, requiring a secure origin for the EME-using
application would not address attacks #13...#15, since the media file could
still be loaded form insecure origins.

Requiring secure origins even for the media files would address attacks
#13...#15, but judging from the comments on this bug, that sort of requirements
seems to be considered particularly infeasible.

Attacks #13 and #9 could be addressed by limiting the PSSH boxes to such
(unencrypted) formats that can be validated by the browser (analogously to
browsers validating WebGL shaders before passing them to a shader compiler
whose bugs aren't under the control of the browser vendor).

Attacks #14 and #10 could be addressed by making sure that the CDM doesn't
subsume any functionality that it logically does not need to (e.g. does not
perform MP4 demultiplexing) and then making the leap of faith that the AES-CTR
decryption step is narrow enough to be bug-free.

Attacks #15 and #11 could be addressed by performing cryptographic integrity
checking as part of the decryption step, but as I understand it (please correct
me if I'm wrong; I don't have the CENC spec at hand) neither WebM encryption
nor CENC in MP4 involve MAC checking leaving the formats vulnerable to CTR
malleability attacks. This means that an attacker who gets to replace data in a
media file can at least fuzz the codecs with random data, which might not be
enough for exploit development. However, to the extent there are parts of the
codec data whose plaintext in a particular position is known or guessable and
the codec implementation has a bug that can be exploited by manipulating data
at that position, it is possible for the attacker to manipulate the data that
way. Hopefully, there's the mitigating factor that since the codec data is
supposed to be *compressed*, runs of data whose plaintext is known hopefully
aren't long enough to hold shell code. Switching away from CENC to add
integrity checking seems too drastic in terms of the compatibility properties
that EME seeks.

However, attacks #15 and #11 are CDM-specific attack surface only if the codec
implementation is CDM-specific. If the browser uses the same platform codec
implementation in non-DRM cases, bugs in the codec can be exploited without EME
(unless the browser validates all data before passing it to the codec in the
case where the data is not encrypted, but that seems unlikely due to
performance reasons).

(In reply to Mark Watson from comment #50)
> Commercial CDNs charge significantly more for HTTPS services than HTTP.
> Migrating a large amount of traffic from HTTP to HTTPS has significant
> capacity / re-engineering implications. There are also operational issues
> that negatively impact user experience. So it's a significant issue.

The largest chunk of traffic is the media data, which is "passive mixed
content" if embedded from an insecure origin into a page coming from a secure
origin. In the comment of mine that you are replying to, I intentionally
mentioned blocking mixed-content XHR and Web Sockets but didn't mention
blocking mixed-content media data. When assessing the feasibility of
restricting EME to secure origins, requiring the EME-using script to run in the
context of a secure origin and the key acquisitions to happen with a secure
origin is one thing and making all the media data come from secure origins,
too, is another thing.

(In reply to Mark Watson from comment #59)
> even though the technical rationale is weak / restricted to
> CDMs that do not follow the privacy / security mitigations in the document
> (but nevertheless somehow get themselves integrated into a UA).

Suppose someone seeks to make a browser with the level of care to privacy that
the members of the Chrome team show here for a device has a CDM for a
Netflix-supported Key System but the device instance-specific CDM keys are
factory-provisioned and unchangeable as a consequence of a higher-than-desktop
robustness solution. Assuming that Netflix continues to serve the application
from an insecure origin to desktop browsers would Netflix serve the application
from a secure origin just to such a browser if requested by the browser maker
or leave it up to the browser maker to get the CDM implementation and the
manufacturing flow changed if better privacy properties are desired?

That is, how realistic is it, really, for the secure origin requirement to be
contextual to a particular CDM implementation? It seems to me that unless major
desktop browsers restrict EME to secure origins, browsers on devices with
different CDM identifier stickiness characteristics aren't in a position where
they could demand different treatment (i.e. to be served from secure origins
only).

(In reply to Joe Steele from comment #60)
> The key requests made by some DRMs fall exactly into this category of "very
> short connections". One packet out, one packet in. The overhead of
> negotiating an SSL channel (which may ultimately add nothing to the
> security) can be almost 100%.

Not necessarily if the key requests get multiplexed into a pre-existing
SPDY/HTTP2 connection that's open to the server where either the HTML page
already came from, which is quite possible when the key requests go over XHR
and go to an application server in front of the actual key server so that the
application server can check cookies.

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

Received on Friday, 22 August 2014 14:43:40 UTC