On Fri, Jan 30, 2015 at 5:51 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:
> I think the point here is that we want to free ourselves from needing the > chemspill over OpenH264 memory hazards if we find them (since the code is > relatively new). > Note that with OpenH264 memory issues, we actually chemspill OpenH264, not Firefox, because Firefox will auto-update from Cisco. -Ekr > With gstreamer, I think we just blacklist vulnerable versions. > > On Fri, Jan 30, 2015 at 3:15 PM, Mike Hommey <m...@glandium.org> wrote: > > > 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 > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
