Re: Creating effective RansomWare with EME

Hi Aaron,

I do not see any examples in your reference [0] where the attack vector is
the audio or video data itself, which is the part that would be relevant
for EME. EME does not affect the operation of any of the attributes on the
media element (which are cited as examples in your reference). [1] and [2]
do not appear to be relevant either.

If you could provide more details, we could look into this. The W3C work
has addressed many of the security (and privacy) criticisms which have
traditionally been leveled at DRM, something that would probably not have
happened to such an extent had the work been done elsewhere.

...Mark

On Mon, Jun 20, 2016 at 12:01 AM, Aaron Zauner <azet@azet.org> wrote:

> Hi,
>
> TAG Chairs in CC.
>
> What does protect users from attackers creating RansomWare with EME?
> Reading the spec. I couldn't spot something that would hinder that.
>
> Consider code execution via JS in <audio> and <video> tags [0]. This has
> been demonstrated over and over again in the past [1] [2]. You're now
> providing and interface for these to be protected and encrypted in a
> DRM-fashion. This means as an attacker I can exploit this API (and
> malicious attackers do not really give a shit about legal implications in
> any case) to create RansomWare in the Browser, am I not on point?
>
> I will not go into further details for fear of EME becoming a standard and
> malicious entities actually implementing this. But I would go so far as to
> publish a research paper once this happens, including -- as always -- PoC
> code in the hope that Browser Developers will simply drop support for EME.
>
> This standard and it's process is a disgrace to the W3C and Open Standards
> community [3]
>
> (For obvious reasons I'm not subscribed to this mailing-list, please reply
> directly with the ML in CC)
>
> Aaron
>
> [0] https://html5sec.org
> [1] https://bugs.chromium.org/p/chromium/issues/detail?id=386988 (only
> one example)
> [2] https://hackerone.com/sandbox
> [3] https://opensource.org/osr-drm
>

Received on Monday, 20 June 2016 15:33:04 UTC