1100304 - Cisco's OpenH264 binary blob is downloaded without prompting the user

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[Luke Bratch]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.8) Gecko/20140807 Firefox/24.8 PaleMoon/24.8.0b1
Build ID: 20140807220009

Steps to reproduce:

Open Firefox 33 onwards without media.gmp-gmpopenh264.{autoupdate,enabled,provider.enabled} set to false.


Actual results:

The following unknown binary was downloaded and marked as executable:

-rwxr-xr-x 1 bratch users 1030172 Sep  2 21:27 /home/bratch/.mozilla/firefox/z5iemd9q.default/gmp-gmpopenh264/1.1/libgmpopenh264.so


Expected results:

A prompt for the download should occur - an unknown, ~1 MB (bandwidth concerns) executable binary blob (security/privacy concerns) should not downloaded automatically.

I realise that the preferences mentioned above will disable the download, but:

1. The preferences are difficult to set for users
2. They are inconvenient to set before a new profile is created
3. The names of them are difficult to find outside searching through bug reports
4. Very few users will be aware of these preferences

Comment 1

[Richard Z.]

At least Fedora and Gentoo have bugs on this:
https://bugzilla.redhat.com/show_bug.cgi?id=1155499
https://bugs.gentoo.org/show_bug.cgi?id=525810

This behaviour is also fairly irritating when testing extensions with "cfx run", I really do not need to download this plugin every 5 minutes.

Also not exactly everyone will need this plugin routinely so it should be downloaded on demand.

Comment 2

[Christoph Anton Mitterer]

And there's Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769716

It's really outrageous what Mozilla does here,... no one knows what's actually in that binary blob, so Mozilla intentionally compromises their users security.

Comment 3

[Richard Z.]

In addition to other issues, the binary plugin is also downloaded in safe mode. I don't think this is expected behavior.

https://bugzilla.mozilla.org/show_bug.cgi?id=1105990

Comment 4

[Luke Bratch]

An example of the security concerns mentioned in this bug report has come to light:

http://tools.cisco.com/security/center/viewAlert.x?alertId=36500

Comment 5

[Sören Hentzschel]

(In reply to Luke Bratch from comment #4)
> An example of the security concerns mentioned in this bug report has come to
> light:
> 
> http://tools.cisco.com/security/center/viewAlert.x?alertId=36500

Firefox is not affected, see https://bugzilla.mozilla.org/show_bug.cgi?id=1105688#c1

Comment 6

[Richard Z.]

(In reply to Sören Hentzschel from comment #5)
> (In reply to Luke Bratch from comment #4)
> > An example of the security concerns mentioned in this bug report has come to
> > light:
> > 
> > http://tools.cisco.com/security/center/viewAlert.x?alertId=36500
> 
> Firefox is not affected, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1105688#c1

I believe this is another bug, this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1106067

It appears to be fixed but no idea if and when the fix was propagated to the binary.

It is like with any other plugin, it will surely have security problems over time.

I have several profiles for different kind of usage and for most of those almost all plugins are disabled. I may have soon use for OpenH264 but than I want to create a separate profile with that plugin enabled which I will use for the pages where I want it.

Comment 7

[Christoph Anton Mitterer]

(In reply to Sören Hentzschel from comment #5)
> Firefox is not affected, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1105688#c1
If the blob is really that one, which is difficult to tell since it's a blob.

Comment 8

[Luke Bratch]

Indeed.  To be clear, I wasn't saying that Firefox is affected, but strengthening the ideas that:

1) Plugins from a different project increase vulnerability risk, whether binary or source
2) One cannot verify or trust whether Firefox is affected, due to the nature of the precompiled binaries *

Both issues would be less severe with an informed user choice following a prompt, which is what this bug report is about.

* I have seen the suggestion of the binaries being verifiable in other bug reports, but have not yet seen a recipe for compiling an identical binary.

Comment 9

[Florian Bender]

The source code of the blob is readily available at https://github.com/cisco/openh264 – there are ongoing efforts to allow reproducible builds which will then allow verification of the blob.

Comment 10

[Kai Hendry]

Just noticed this in Webconverger, the distro I maintain.
http://s.natalian.org/2014-12-21/aboutblank.pcapng.gz <-- wireshark pcap
http://s.natalian.org/2014-12-21/ciscobinary.png <-- wireshark screenshot

IIUC it's downloading this binary blob over HTTP?

Since Webconverger wipes the profile clean between sessions, I see this is downloaded again and again.

What's not clear to me is what happens if this feature is disabled? I was under the impression gstreamer plugins provided MP4 playback?

Comment 11

[Richard Z.]

(In reply to Kai Hendry from comment #10)
> Just noticed this in Webconverger, the distro I maintain.
> http://s.natalian.org/2014-12-21/aboutblank.pcapng.gz <-- wireshark pcap
> http://s.natalian.org/2014-12-21/ciscobinary.png <-- wireshark screenshot
> 
> IIUC it's downloading this binary blob over HTTP?

yes, there is another bug open regarding the http connection. The fingerprint is verified independently of the insecure connection but it makes sensitive information trivially easy to snoop before the user even visits the first webpage.

> Since Webconverger wipes the profile clean between sessions, I see this is
> downloaded again and again.

Yes, that is very silly. Even worse when developing extensions, every "cfx run" is a new download.

Do you save/restore user configs and extensions anyhow?

Comment 12

[Kai Hendry]

(In reply to Richard Z. from comment #11)
> Do you save/restore user configs and extensions anyhow?

No, we don't. I've set the aforementioned prefs and now it doesn't seem to download the blob anymore https://github.com/Webconverger/webc/commit/02241440d5f494da9adab92cd6c8106d0e8623f7

Still don't quite understand **what the blob was for** initially since I can playback MP4s just fine without it. Furthermore FF downloading a remote binary and executing it, is not cool. I'm promising my clients that all browser updates are verified by myself and come down via git. So I hope these prefs are the end of it.

Comment 13

[cajbir (:cajbir)]

(In reply to Kai Hendry from comment #12)
> Still don't quite understand **what the blob was for** initially since I can
> playback MP4s just fine without it. Furthermore FF downloading a remote
> binary and executing it, is not cool. I'm promising my clients that all
> browser updates are verified by myself and come down via git. So I hope
> these prefs are the end of it.

OpenH264 is used for WebRTC decoding of H.264. GStreamer on some platforms, other system decoders on others, is used for MP4 playback on the <video> element.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to cajbir (:cajbir) from comment #13)
> (In reply to Kai Hendry from comment #12)
> > Still don't quite understand **what the blob was for** initially since I can
> > playback MP4s just fine without it. Furthermore FF downloading a remote
> > binary and executing it, is not cool. I'm promising my clients that all
> > browser updates are verified by myself and come down via git. So I hope
> > these prefs are the end of it.
> 
> OpenH264 is used for WebRTC decoding of H.264. GStreamer on some platforms,
> other system decoders on others, is used for MP4 playback on the <video>
> element.

Specifically, OpenH264 is used for *guaranteed low latency* video decode, which most platforms' don't provide, and H.264 guaranteed low latency encoding which most platforms' don't provide. Low latency is important for WebRTC. 

This bug should be in Firefox component, since it's against the GMP downloading code, not the Gecko code.

Comment 15

[Benjamin Smedberg]

This download is by design.

Comment 16

[Richard Z.]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #15)
> This download is by design.

vow.. so it is "design" that every time I do "cfx run" the beast will beat the network with a half MB network traffic?

Congrats to this design.

Comment 17

[Georg Fritzsche [:gfritzsche]]

See this blog post for the background on this: http://andreasgal.com/2014/10/14/openh264-now-in-firefox/
Please take any further discussions to mailing lists like firefox-dev or dev-media.

Comment 18

[Luke Bratch]

I've started a thread on firefox-dev, for those interested: https://mail.mozilla.org/pipermail/firefox-dev/2014-December/002586.html