- From: Mark Watson <watsonm@netflix.com>
- Date: Mon, 20 Jun 2016 08:32:27 -0700
- To: Aaron Zauner <azet@azet.org>
- Cc: "public-html-media@w3.org" <public-html-media@w3.org>, Tim Berners-Lee <timbl@w3.org>, Daniel Appelquist <dan@torgo.com>, peter.linss@hp.com
- Message-ID: <CAEnTvdAQwLrOZUr-Q7UCRW0mxbXr3oCV5oQuVAvbEGLS-z8i6w@mail.gmail.com>
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