1194875 - Don't blacklist multimedia components without a version check OR a way to override in about:config

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect, P5)

Description

[Jonas Thiem]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150812030206

Steps to reproduce:

Apparently, the following happened:

"The gstreamer element h264parse has been blacklisted due to the security bug below. The blacklisting has been reversed in distro builds that include this fix."

Now what if someone doesn't use the distro build? It seems odd that you would cripple playback of a very important media source (h264) for all your users _without possible disabling of the backlisting_ because of a security hole while apparently not including a version check either. (I'm assuming since I checked the CVE-2015-0797 notes myself and it says that 1.4.5 which I have has it fixed)

As a result, I'm sitting here on Ubuntu and Firefox no longer plays H264 because of some security issue that has already been patched (so I don't need protection, thanks!), and now half of Youtube no longer works because Firefox doesn't even allow me to simply tell it to not do that.

If you can't verify whether the component on the user's computer is vulnerable or not, you really should allow overriding it without rebuilding the entire browser manually. If you want to be sure nobody does this by accident, make in about:config option or something.

It just seems like the wrong approach to have some media source entirely broken for large parts of your userbase just because at some point in the last months it happened to have a now patched vulnerability. There has to be a better way.

Comment 1

[Ralph Giles (:rillian)]

As I said on lwn, I couldn't figure out how to do this. Patches welcome though.

Comment 2

[Jonas Thiem]

Sorry that I was a bit harsh, I was a bit frustrated since it took me a while to find the cause of this (with multiple people claiming gstreamer must work for me and obviously I haven't installed all packages) and then it seemed the blacklisting couldn't even be disabled - which I heard now is not entirely correct either.

As for the future, maybe it would be worth asking gstreamer upstream about this? If there's no usable gstreamer API call to check for a codec's detailed version, maybe one could be introduced.

Comment 3

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to Jonas Thiem from comment #2)
> Sorry that I was a bit harsh, I was a bit frustrated since it took me a
> while to find the cause of this (with multiple people claiming gstreamer

We share your frustration. You may find bug 1207429 interesting.

Comment 4

[Jean-Yves Avenard [:jya]]

gstreamer is going in bug 1234092