W3C home > Mailing lists > Public > public-html-media@w3.org > June 2016

Re: Creating effective RansomWare with EME

From: David Singer <singer@apple.com>
Date: Mon, 20 Jun 2016 08:10:37 -0700
Cc: public-html-media@w3.org, timbl@w3.org, dan@torgo.com, peter.linss@hp.com
Message-id: <819D2883-F93C-464D-BAE8-A1BE33A4AEC3@apple.com>
To: Aaron Zauner <azet@azet.org>
Isn’t the essence of RansomWare that it relies on installing something?  Is there an installation step in EME, or is it, as defined, an API to a pre-existing module on the client-side?


> On Jun 20, 2016, at 0:01 , 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

David Singer
Manager, Software Standards, Apple Inc.
Received on Monday, 20 June 2016 15:11:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 20 June 2016 15:11:46 UTC