On Fri, Jan 30, 2015 at 12:33:55PM -0500, Randell Jesup wrote: > >On Thu, Jan 29, 2015 at 06:57:30AM +0900, Mike Hommey wrote: > >> So, in practice, because the h264 code is not sandboxed on some setups, > >> we're disabling it so that vp8, which is not sandboxed either, is used > >> instead. We have about the same amount of control over openh264 and > >> vp8 code bases. What makes the difference? > > > >This is more a question for the WebRTC module leadership, but: assuming > >the attacker can choose the codec (do we always secure the media content > >at least as much as the script that set up the session?), the set of > >vulnerabilities is the union of the codecs' vulnerabilities, and adding > >a codec can only add more of them. > > > >Possibly also relevant: we already prefer VP8 over H.264 on desktop. > > In theory VP8 is not inherently 'safer' than H.264. In practice, the > OpenH264 codec is less mature, especially from a security perspective - > VP8 (due to our and Google's use and testing of it) has been pretty well > wrung out. We could consider moving VP8 encode/decode to a sandbox; > there is a performance/memory cost to this. I don't think we've had > many sec bugs in VP8 in recent years, so the risk/cost/reward tradeoff > may not be great. > > An added concern for OpenH264 raised by various people has been that > OpenH264 is a 3rd-party download, which raises concerns about the > possibility of a compromised or evil plugin. We are somewhat avoiding > that currently because we're doing the builds for Cisco, and we're also > looking for ways to create a bit-level reproducible build setup so > people can verify/validate that the binaries are what they say they are. > > The other aspect here is that the same concerns will apply to any > EME/etc plugins using the GMP interface/sandbox; without seccomp-bpf, we > cannot ensure the plugins aren't doing something evil (or tracking > users), and those would be closed-source. So there's even more reason > to disable GMP on these older linux systems.
All GMP plugins don't need to be treated the same. The reason OpenH264 is one is bound to the fact that we can't ship it like we do vp8. And iirc, It's already special cased in the GMP code anyways. Moreover, we currently support h264 decoding with ffmpeg through gstreamer. ffmpeg doesn't really have a great track record from a security perspective, although I don't know how much of it affects the h264 decoding code. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
