An unfortunate description [LWN.net]

An unfortunate description

Posted Mar 15, 2012 18:04 UTC (Thu) by khim (subscriber, #9252)
In reply to: An unfortunate description by rqosa
Parent article: Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (ars technica)

It seems like all that the Gecko developers would need to do is to make a whitelist containing entries for only VP8, Ogg, and Matroska (possibly allowing for users to edit the whitelist on their own installations, at their own risk), and leave it up to GStreamer to decide which particular implementation of those codecs and containers it will use.

What this whitelist will actually accomplish? VP8, Ogg, and Matroska parsers - they all have bugs. Just today I've tried to watch video and it crashed demuxer. I've used alternative one (“lavf” instead of “mkv”) and was able to see the video. But the very fact that I was able to crash player means that this particular version should not be included in whitelist.

That way, all of the many other codecs and containers supported by GStreamer are excluded from the "attack surface" that the browser exposes to untrusted remote servers.

This still leaves wast attack surface. Unfortunately.

When app developers adopt the NIH attitude like Mozilla developers have done (or alternately, when they do use third-party libraries, but fork them and build the forked versions into the app, which is what Chromium/Chrome developers tend to do), it violates the engineering principle of modularity (a.k.a. "do one thing and do it well"), and ultimately causes a tragedy-of-the-commons where all app developers need to go to great effort to implement pieces of functionality that have already been implemented elsewhere (thus negating one of the major potential benefits of FLOSS).

Now we are down to basic handwaving. The fact is: codec developers don't consider it a “big deal” if you can crash their creations using “bad files” - and aforementioned “advanced GPU-based capabilities” are especially notorious. When and if most codec developers will start consider such things really important it'll be safe to use them in browser. I, for one, don't hold my breath.

(Log in to post comments)

An unfortunate description

Posted Mar 15, 2012 18:59 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> What this whitelist will actually accomplish?

It would decrease the attack surface to exactly the same "size" as it currently is in Gecko's built-in video playback implementation.

> But the very fact that I was able to crash player means that this particular version should not be included in whitelist.

No, what that really means is that "this particular version" needs to be fixed upstream. (The more users it has, the faster its bugs will be found and fixed — and if Firefox depends on it, that means it has lots of users.)

> This still leaves wast attack surface. Unfortunately.

Maybe it is a vast attack surface, but it's exactly the same size as the attack surface that Gecko already has.

> The fact is: codec developers don't consider it a “big deal” if you can crash their creations using “bad files”

That's irrelevant, because Gecko is using the same codec and container libraries (libvpx, libogg, libmatroska) that the rest of the FLOSS ecosystem uses (modulo some changes that the Mozilla developers have made in their in-tree copies of those libraries, maybe). And it hurts the FLOSS ecosystem if they're putting security fixes into their in-tree library copies instead of upstreaming them.

An unfortunate description

Posted Mar 15, 2012 19:17 UTC (Thu) by rqosa (subscriber, #24136) [Link]

(And libvorbis too, of course.)

An unfortunate description

Posted Mar 15, 2012 19:35 UTC (Thu) by gmaxwell (subscriber, #30048) [Link]

> because Gecko is using the same codec and container libraries

As part of the upstream team for libogg, libtheora, and libvoribs, I can say Mozilla is excellent about taking things upstream (admittedly easier becaue they've hired some of the upstream developers). In fact, for the past two years 100% of the their changes to these libraries have been upstream, at least in the SCM, first as far as I can tell.

But that has heck all to do with what distributions actually ship— and some upstreams have longer pipelines or have outright rejected their changes.

For example, when libvpx was first released Fedora shipped a known vulnerable copy of it— even though I pointed it out and protested— because libvpx upstream had not taken the fixes (being shipped in all the browsers) yet because they hadn't decided which way it should be fixed (because the fixes had potential bitstream implications).

Moreover, vulnerabilities can arise from unexpected interactions (e.g. will a different version of a library returns frames with different alignment?) and may have different bugs/features and Mozilla feels responsible for having maximally uniform featureset across platforms (otherwise you get websites OptimizedForFirefoxOnWindows, partially defeating the open web).

An unfortunate description

Posted Mar 15, 2012 20:07 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> when libvpx was first released Fedora shipped a known vulnerable copy of it

Well, the same principle that applies to external library dependencies also applies to Linux distributions— app developers shouldn't try to work around bugs in the distro, they should instead get those bugs fixed.

> Mozilla feels responsible for having maximally uniform featureset across platforms (otherwise you get websites OptimizedForFirefoxOnWindows, partially defeating the open web).

Oh really? IIRC, they enable WebGL by default on Windows but disable it by default on Linux.

An unfortunate description

Posted Mar 15, 2012 19:52 UTC (Thu) by tterribe (✭ supporter ✭, #66972) [Link]

> That's irrelevant, because Gecko is using the same codec and container
> libraries (libvpx, libogg, libmatroska) that the rest of the FLOSS
> ecosystem uses (modulo some changes that the Mozilla developers have made
> in their in-tree copies of those libraries, maybe).

I maintain these libraries for Mozilla. I do my damndest to make sure they are not vulnerable, and all of my fixes go upstream. Sometimes before they even land in Firefox (because for a number of them, I _am_ the upstream... though the difference is usually no more than a few hours). Because I know that even though the vast majority of our users (on non-Linux systems) will use our in-tree copies, Linux distributions will still insist on building against the system libraries.

Ideally, of course, everything would be fixed everywhere. But the reality is that for the past two years (at least, I didn't check further), 100% of the issues that have been reported against these libraries have been reported to Mozilla first. Distributions then proceeded to not ship the upstream changes, or to ship new upstream code containing new vulnerabilities without proper testing and vetting. This is inevitable: testing is hard, mistakes will happen, and people who have to maintain tens of thousands of packages have different priorities than a project with a few dozens of dependencies (especially with the effort to upgrade repeated independently by every distribution), even though everyone involved is trying to do the right thing. But if your Firefox has been vulnerable to an attack (especially a known one) via a codec library since we first implemented <video>, chances are it's because your distribution compiles it against the system libraries, instead of ours.

An unfortunate description

Posted Mar 15, 2012 20:37 UTC (Thu) by rqosa (subscriber, #24136) [Link]

> But if your Firefox has been vulnerable to an attack (especially a known one) via a codec library since we first implemented <video>, chances are it's because your distribution compiles it against the system libraries, instead of ours.

Consider what's likely to happen, though, if all apps depending on a given library use the system copy, and compare it to what's likely to happen if all apps depending on the library use their own copy. If they're using the system copy, the bug gets found by the first app to trigger it, and then it gets fixed for all users of the library. If the apps are all using bundled copies, it's likely that the fix won't propagate quickly from the first app to the others — and if it does propagate quickly, then it triggers a thundering herd of package updates (which equates to lots of extra work for distro package maintainers).

That's what I meant when I said that the use of in-tree dependencies is a tragedy of the commons: when one app uses in-tree dependencies, it might improve that single app in the short term, but in the long term it hurts the FLOSS ecosystem as a whole. Therefore, I argue that the original article here has got it backwards: for Gecko to begin using an operating system-provided GStreamer for video playback is actually the "idealistic" (or "long-term") option, not the "pragmatic" (or "short-term") one.