Chromium unconditionally downloads binary blob

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909

by fractalcat • 11 years ago

550 176 11 years ago

bugs.debian.org

AndrewDMcG• 11 years ago

From the comments on the debian bug, this appears to have been fixed in Chromium. https://code.google.com/p/chromium/issues/detail?id=491435

jug2• 11 years ago

Strange how they "fixed" it by making it opt-out rather than opt-in, given the culture collision here. Google really likes NaCl a lot for being a feature with almost no third party adoption.

rockdoe15• 11 years ago

That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.

mortehu3• 11 years ago

While there's "almost no third party adoption", there are two pretty significant uses: The Flash player and the PDF viewer. Browsers that rely on NPAPI for these get all of Adobe's security bugs on top of their own. You may say that Flash and PDF doesn't exist in your view of the web, but it definitely does for many people.

dtech2• 11 years ago

Note that it wasn't an upstream bug per se, they added a build flag to disable it.

JoshTriplett• 11 years ago

Unfortunately, that fix disables the functionality completely, rather than making it so that the sandboxed hotwording module can be used if enabled by the user.

rockdoe15• 11 years ago

I advise not reading that bug, some of the later comments will give you brain cancer.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909#51

Downvotes? So you agree with this?

"I seriously consider the good faith of an such upstream which does these kinds of things"

"But basically secretly downloading it leads to the question of possible malicious intent (and everyone knows that Google&Co. do voluntarily and/or forcibly cooperate with NSA and friends)."

"while I haven't looked at the code, I wouldn't even be surprised if the downloading itself is done insecurely."

"Worse, chromium isn't the only such rootkit-downloader,... e.g. FF which secretly downloaded the OpenH264 blob."

Really if you condone this attitude then I can only say...well I won't say it but it isn't nice. Not only that, everyone seemingly ignores the: "Note that the binary blob is executed throught native client, which is not enabled by default" part.

You people are so beyond reasonableness I find myself defending Chrome/Google. I can't believe this.

lambada• 11 years ago

By 'some' you mean 'one'.

BRG_12• 11 years ago

This guy is actually perfectly right. Google doesn't do thing like that by accident. I'm glad there are some sharp guys around to disclose such potentially malicious behavior.

rockdoe15• 11 years ago

Do what by accident? Of course the intent was to include the blob. If Debian wants to get rid of it it should patch Chromium or request it to be made configurable (which is what happened).

But the tinfoil hattery is completely baseless.

dtech2• 11 years ago

Even if malice instead of incompetence is involved, it goes pretty far to call Chromium a "rootkit-downloader" just because it downloads a binary blob.

It could theoretically be a rootkit, but without any evidence to support it this is like calling someone a murderer because he went to the same high school as a murderer.

kibibu• 11 years ago

I think it's totally reasonable, from the Debian mindset. Debian is an open-source zero-binary-blob distribution. You have to deliberately choose to install binary blobs, such as driver firmware etc.

It is the dismissive response which is not appropriate. The responder asserts that the blob is safe and trustworthy, how would anybody know?.

luso_brazilian3• 11 years ago

The tone was inflammatory but the sentiment is valid. Quoting:

Since no one really know which binaries have been downloaded there and what they actually do, and since it cannot be excluded that it was actually executed, such systems are basically to be considered compromised

A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident.

Many people are used to it because of all the training received by the "Java Auto Update", "Google Update Helper" and similar software receiving blank permission to monitor, download and execute closed source software with the same permission as the logged in user.

Despite of that a person that goes to the lengths of using Debian (instead of Ubuntu) and Chromium instead of Chrome certainly expects more from their sources than to allow this kind of behaviour.

It is a security incident and should be treated as one both by Debian and by the community in general.

roel_v• 11 years ago

"A closed source binary being silently downloaded and executed without explicit action by the user or notification to the same is a security incident."

Whereas source code being downloaded, compiled and run is not? Or a script being downloaded and run?

scbrg• 11 years ago

Downvotes? So you agree with this?

Whether we agree or not is not really relevant. Advising people to not read a bug report because one of the comments in the discussion associated with the report doesn't appeal to you is... strange, to say the least.

How do you manage any kind of discussion format if opinions (however wrong they may be) you don't like make you leave the discussion entirely?

rockdoe15• 11 years ago

On the contrary, sometimes ignoring the discussion is the only way to stay sane and make progress because there are an infinite number of people with "opinions".

In this case the original report is informative, what comes after (up to 2 posts now) probably isn't going to be.

samwillis• 11 years ago

The binary blob is targeted at Native Client and so only runs in the google chrome sandbox. There is no security issue here.

kpcyrd• 11 years ago

"Don't worry, it's running as restricted windows user, there is no way it could possibly ever... oh"

blfr• 11 years ago

Sandboxed unknown code is still better than non-sandboxed unknown code.

nadams• 11 years ago

We are totally secure because all of our Windows users run with limited privileges!

...that is until the domain admin checks his email and opens a malicious PDF.

pjc50• 11 years ago

But it's closed source, which is a criterion that Debian have historically regarded with a very high priority.

longsleep• 11 years ago

Another reason to switch to Iridium Browser. It has Google search disabled by default and even if you switch search to Google, Voice search and hot-words stay off until you manually enable it.

https://iridiumbrowser.de/

pmontra• 11 years ago

I didn't know about Iridium. I'll give it a try.

mikegioia• 11 years ago

I'm running Iridium and this module is loaded, at least "chrome://voicesearch/" loads the same info.

castell• 11 years ago

another one is "Iron browser"

mnnsmnn• 11 years ago

Hm, when I try to download Iron's source code ("for Coder"), a Rapidshare page "Our services have been closed. Thank you for your understanding!" pops out. How convenient.

pknight• 11 years ago

Which is not to be trusted in the slightest

golergka• 11 years ago

https://code.google.com/p/chromium/issues/detail?id=491435

This fix is an opt-out with a compilation flag. Also, I don't know much about Chromium development process, so it might be irrelevant, but I only see source updates, without any updates in the documentation.

belorn2• 11 years ago

A bit surprised that there is no security CVE report attached. Debian policy is that binaries are vetted by a debian developer, sorted into Main, Contrib and Non-free, cryptographically signed and later verified by the client package system. The bug could allow arbitrary code to be installed and run without any of the above process if someone MitM the connection between the binary file and the client.

simoncion4• 11 years ago

Isn't the blob downloaded from Google's servers over a HSTS and cert-pinned TLS connection?[0] If someone has MitM'd Google, it's gonna be a bad day for a lot of people.

From my POV, the thing that's actually bothersome about this issue is that a closed-source blob is automatically inserted into a project that I -and others- had understood to be completely open-source.

The fact that the Chromium Google Hotword code was later made opt-out -rather than opt-in- through a build-time configuration option is similarly troubling.

[0] IIRC, Chromium does support enterprise TLS snooping/interception devices, but those certs have to be loaded into Chromium before such devices will work.

belorn2• 11 years ago

Since it doesn't use the normal ways to download extension, I would assume it does not use TLS connection. Secret downloads has the problem to display certification errors and similar things to the users, so they would likely have to reimplemented quite a few code paths to make that work properly. https and tls is also not mentioned in either bug threads, which is a worrying sign.

If it uses TLS, then the bug is less exploitable but does still violate security policy of the vetting process, signed code and license classification (closed-source blob). At minimum, it leaves anyone vulnerable to arbitrary code injection from Google.

rmc• 11 years ago

If someone has MitM'd Google, it's gonna be a bad day for a lot of people.

Didn't foreign government agencies already do that? (e.g. NSA?)

codys2• 11 years ago

Arbitrary code controlled by a single organization (Google) is still arbitrary code.

kiallmacinnes• 11 years ago

And their system still does this for everything they distribute. This is no different really to, for example, pythons PIP. At least, as far as policy around signing of all Debian archive content.

Granted.. This is a binary blob downloaded without consent which is an issue, its just not an issue with the Debian archive distributing unvetted code.

zoner• 11 years ago

Switched to Firefox as the primary browser just to be sure :)

codazoda• 11 years ago

There's a comment there indicating that FF has done the same in the past with an H.264 blob.

The conspiracist in me wonders why both these major browsers have downloaded and maybe executed binary blobs. Is it purely a convenience feature in the browser? Is it a secret order? That last question would have been silly a decade ago but we all know it's entirely possible now.

icebraining2• 11 years ago

Firefox's blob is open source, though (OpenH264 is on Github and is BSD-licensed).

pgeorgi• 11 years ago

the open h.264 blob thing is annoying, but it's supposed to be a reproducible build of open source software.

The reason why there's a blob is because for that binary, Cisco pays the patent licenses.

So you can verify the source for any issues, verify whether it matches the binary, and work around MPEG-LA licensing at the same time (there are caps, and Cisco seems to have calculated that even when running into them, they're still better off with having webrtc support h.264 everywhere).

strcat7• 11 years ago

Firefox has similar code to download the proprietary EME plugin but it prompts the user about it first, which Chromium could be doing here.

pix64• 11 years ago

http://andreasgal.com/2014/10/14/openh264-now-in-firefox/

nivla2• 11 years ago

Wasn't Firefox recently called out for including proprietary integration from Pocket and Hello on their new versions by default which cannot be removed but only disabled? [1]

I wonder if I should just switch back to IE6 that has no microphone and webcam support, but then there is ActiveX! :(

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

rhelmer• 11 years ago

Can you please cite where you read that proprietary blobs are used? IIRC the Pocket client is open-source, and so is the Hello client (it's basically a webapp that uses WebRTC)

JohnTHaller• 11 years ago

The client side code for Pocket integration is open source, so you can look at it if you'd like. You can disable it just by removing the Pocket icon from the toolbar. Plus, as Firefox uses lazy loading, once the Pocket icon is removed, the integration code will never be run.

Manishearth• 11 years ago

Hello is just a thin wrapper around WebRTC (an open protocol)

Pocket is just a button that does a couple of AJAX calls to the Pocket site.

Both do have closed source code online, but when you click them it's pretty obvious that they are talking to some online service which may or may not snoop. You even have this "danger" when using Sync in any browser. In all these cases it's very clear what's going on.

When you use Pocket you know that the URL of the page you were visiting was sent to some service. When you use Hello you know that some routing service might be able to snoop on your call (I believe there's some encryption here though, but I'm not sure). When you use Sync you know that you're sending data to the server.

When you enable "Ok Google" detection in an open source software one would expect that the "Ok Google" detection is done locally in open source, verifiable code, and only after this detection is triggered, will sound be sent to the server. If this blob was instead some open source code, one would be able to verify that sound is only sent to the server when it is expected. But now that it's a blob, you don't have this guarantee. It could theoretically send periodic sound snippets to the server without you noticing, since it's listening on the microphone all the time.

That's the difference. Firefox's proprietary integration has verifiable triggers. It won't talk to a proprietary service unless you ask it to, and when it does you can verify what data it is sending.

On the other hand, this blob has no verifiable triggers. Yes, it is disabled by default (verifiably, apparently), but when enabled the data it collects and sends is not verifiable.

(Firefox also does have some blobs -- one for H.264, but the code behind it is open source, the blob is distributed for licensing reasons, and one for EME, but the EME blob is downloaded only with a confirmation which informs the user what is going on)

kekebo• 11 years ago

I opened a ticket in Chromium's Google Code repo, feel free to jump in: https://code.google.com/p/chromium/issues/detail?id=500922

jwise0• 11 years ago

Please read the original thread. This was already reported as: https://code.google.com/p/chromium/issues/detail?id=491435

hoers2• 11 years ago

I did, the ticket you linked has been closed with 'adding a opt-out flag' as solution. I opened another one to discuss it's behaviour in general, wether it should be:

1) opted-in by default

2) not ask user for permission (or notify him in any way)

3) hide the extension from the extension list

4) record audio without permission

spdustin• 11 years ago

So, if the article was titled "Chromium downloads and activates closed-source eavesdropping software on all its devices, bypassing any OS alerts", would that be too wordy? It's meant to be a little tongue-in-cheek, admittedly, but it seems to me that's exactly what they did.

Isn't Chromium behind the enterprise chromebox/chromebook stuff too? And does this mean that Chrome itself may, or has already, install eavesdropping software and activate it without my knowledge?

Edit: I see from a sibling comment that OS X has this eavesdropping software installed, so that leads me to believe that everyone running chromium devices will have this activated, and that it's going to be part of Chrome soon, if it isn't already.

I know it's hyperbole to call it "eavesdropping software", but I also know how many people here were unsettled by "OK Google" and "Alexa!" (Amazon Echo), and I really do want to understand how folks here feel about the intrusion.

marcosdumay• 11 years ago

Chrome is eavesdropping software. Claiming it was installed without authorization does not cut it.

By its turn, Chromium's only selling point was that it was free of the eavesdropping features.

fla• 11 years ago

Any idea what is the executable doing ?

strcat7• 11 years ago

It's an extension running in the usual extension sandbox with permission to access the microphone. It's the "Ok, Google" implementation. It's a proprietary blob so you'd need to reverse engineer it to figure out exactly what it's doing.

jimrandomh• 11 years ago

The binary blob in question is hotword-x86-64.nexe with sha256sum 8530e7b11122c4bd7568856ac6e93f886bd34839bd91e79e28e8370ee8421d5a.

This is labelled as being a "hotword" implementation, ie, something that will monitor the microphone until someone says "OK google", then start listening and transmitting the following words for a search. However, there is no guarantee that it does what it says it does; in particular, it might instead accept instructions to transmit audio from particular parties that Google wants to spy on.

I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed.

This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android, twice: once with the "Play Service Framework", which is a collection of APIs added to Android but theoretically independent of it, and again with Google Glass, which ran an entirely closed-source fork. In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.

laumars6• 11 years ago

I understand there are likely to be many uninvolved engineers within Google who have access to the source code. It would do a lot to restore trust if a few such engineers could take a look through the source code and find out whether it has a remote trigger, and whether the source code in Google's repo matches the file that's being distributed.

That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.

If you're really that paranoid about closed source components within Chromium then the only recourse is not to use Chromium. Thankfully the alternatives are plentiful.

edit: s/Google Chrome/Chromium/g

This is not the first time Google has taken an open-source project and added closed-source components to it. They did the same thing to Android

Android is Google's project to begin with, and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.

In the case of Glass, I did some reverse-engineering and found that it would send all photos taken with Glass, and all text messages stored on a paired phone, and transmit them to Google, with no feasible way to stop it even with root. This was not documented and I don't think this behavior was well understood even within Google.

Did you do a write up of this study? I'd be interested to read it :)

qwe1233• 11 years ago

If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.

The bug in question was spotted in Chromium, not Google Chrome. That would leave Firefox as the only crossplatform and sufficiently up-to-date alternative. Not exactly "plentiful".

anon3_2• 11 years ago

That would prove nothing since there'd be no evidence to back up said statement and that the statement originates from someone on Google's payroll to begin with.

Are you new or unfamiliar with free software? Open source software and web browsers of all things shouldn't have any need for secret code.

It's highly suggestive.

If you're really that paranoid about closed source components within Google Chrome then the only recourse is not to use Google Chrome. Thankfully the alternatives are plentiful.

Sure, why don't we just leave our countries to go live somewhere else when things don't go our way? Why not just give up?

morganvachon3• 11 years ago

Android is Google's project to begin with

It wasn't always; it was an independent company that was acquired by Google in the mid 2000s.[1]

and the closed components which are part of the Play Service Framework have been a part of Android since it's initial release.

No, Google Play Services was first released in 2012, whereas Google's first Android release was in 2008[2], so it most certainly has not been a part of Android from the beginning.

[1] https://en.wikipedia.org/wiki/Android_(operating_system)#His...

[2] http://android-developers.blogspot.com/2008/09/announcing-an...

mgiuca2• 11 years ago

Hi, I'm an engineer from Google responsible for the hotword module.

I understand the concern that a proprietary component may be performing unknown instructions, and indeed Chromium does download hotword-x86-64.nexe on startup, but it has been carefully designed as an opt-in feature. If you do not turn on "Enable "Ok Google" to start a voice search" (in chrome://settings), Chromium will not run the plugin. You do not need to trust Google engineers to tell you this; the open source Chromium code has the logic to decide whether to run the plugin.

I have posted a detailed response (including the link to the place in the Chromium source code where the module gets run) on our bug tracker at http://crbug.com/500922#c6.

cactusface2• 11 years ago

Why do you need to unconditionally download a binary blob? Can't you just download it when "Enable "Ok Google" to start a voice search" is turned on? And also, it's not really open source anymore even though you delay downloading the non-open parts until runtime.

jameshart2• 11 years ago

In a web browser implementation with NaCl support, downloading and executing arbitrary binary blobs is very much a feature, not a bug. The issue here seems to be that Chromium was configured, by default, to download and execute a particular Google-provided binary blob. And now it isn't.

Note that as soon as you go to ANY WEBSITE using Chromium, you are entrusting that site to download you arbitrary data, which could include NaCl binaries, which you're then going to trust Chromium to execute.

marssaxman3• 11 years ago

Is this true of Chrome as well?

If so, I will never run it again.

mynameisvlad2• 11 years ago

Yes, of course it is. Why would it be a thing in the open source version but not the almost-identical closed source version with extra Google goodies. Unless one of those goodies was "remove one of the key aspects of NaCl", which I can assure you, is not.

jameshart2• 11 years ago

I have bad news for you: Chrome is a binary blob of code from Google that has access to your microphone.

snops• 11 years ago

They are sandboxed "machine independent" binary blobs that chrome translates into the local architecture, see https://developer.chrome.com/native-client for details.

Javascript isn't far off binary in terms of readability nowadays with the level of packing/minification, so legibility isn't a deciding factor. Therefore if you can't trust the native client sandbox, why trust javascript, or even HTML from third parties? Native client is part of Chromium, you can audit the source code just as much as for any other language your browser speaks, so why make this distinction?

vidarh• 11 years ago

If the default is to allow those arbitrary pieces of code to obtain audio input from the microphone, then that is a major issue. I very much doubt it allows that by default.

The problem here is not mainly that it downloads and executes code via NaCl, though it's iffy that it does so with no simple way to disable it.

The problem is if it does so and grants that code access to API's' that should be privileged and something the user ought to be aware of.

ethbro• 11 years ago

I thought the code review on the build change was a little more enlightening. More honest discussion.

https://codereview.chromium.org/1160243004

(Names removed as don't think they're important to repost. And not intending this as incendiary. At some point someone needs to ask "How much are we impacting usability by stripping features?")

"1 week ago (2015-06-09 02:17:42 UTC) #19

On 2015/06/09 01:34:04, _ wrote: > On 2015/06/09 01:13:10, _ wrote: > > Done, but I'm going to voice my opposition to this. When I took over the > > hotwording code, there were a number of obscure hoops to jump though to get > this > > to work locally. They've been eliminated. Having to find these pair of > #defines > > and changing them is more obscure to a newcomer than a build flag (that can > > easily be traced through the code). >

What about having a run time flag for enabling hotwording? We would always enable hotwording for Google Chrome builds, and check for it in Chromium builds. That way, Chromium users can make the decision to use the feature, rather than the Chromium distributor. And it won't require hotwording developers to build with GOOGLE_CHROME_BUILD or do any #ifdef hacking.

We shouldn't be exposing feature-enables to end users as runtime switches.

Honestly, I think the right thing to do is for Chromium users to get this by default but have a build switch that can be used to disable it for projects like Debian that feel more strongly about not having any external binary blobs used for anything. I don't think simply disabling this in general for Chromium is correct. It's not true that Chromium by definition should not make use of such blobs, and I think the damage to developers and to more pragmatic users of Chromium-based projects is greater than we should be willing to pay."

azakai• 11 years ago

A major difference is that web content does not have silent access to your microphone, and the ability to monitor you and send information back home.

There are large security differences between what NaCl allows for web content, and what it allows for what Google considers internal parts of Chromium, even if they run in NaCl. Like this blob here, and also Flash, the PDF plugin, and others. All those do a lot more than what a random website would be allowed to.

lasermike026• 11 years ago

The only microphone I trust is the one that is not there.

How sad.

iamcurious• 11 years ago

There are always microphones, everywhere, all the time.

I remember when I was a toddler and they taught me that Santa's elves and God's angels where spying me to make sure I was good. They later told me it was a lie. It became true soon enough.

Fighting for privacy is impossible. We should fight instead for transparency, that means, spying those with power. And we should fight for equal rights, that means, making it hard for people to hurt you with the private knowledge they have from you.

josteink• 11 years ago

So when I've called Google Chrome for "spyware" in the past I can now add Chromium to that list.

Google's not even trying to not be evil these days.

Animats• 11 years ago

Note that although this bug report was forcibly closed, the fix is "This change adds an "enable_hotwording" build flag that is enabled by default, but can be disabled at compile time."

Consider what this backdoor does. It listens to any conversation in the vicinity of the phone and reports it to a remote site. You can't see its keyword list. You can't tell when it's transmitting to the mothership.

Has anyone filed a US-CERT report with Homeland Security on this?

finnn• 11 years ago

vicinity of the phone

What phone? Last I checked this was for the desktop build of Chromium

hoers2• 11 years ago

No but a ticket

https://code.google.com/p/chromium/issues/detail?id=500922

CamperBob2• 11 years ago

Has anyone filed a US-CERT report with Homeland Security on this?

"Yeah, we know. It's ours. Don't worry about it. Go about your business. Pick up that can, while you're at it."

shit_parade22• 11 years ago

Since these things can be opaque, archlinux updated to disable "hotword":

https://projects.archlinux.org/svntogit/packages.git/commit/...

thanks to the maintainer and the FOSS community in general.

amd_• 11 years ago

Not sure why everyone keeps saying "binary blob?", I guess it's similar to when people say "TCP protocol".

Chromium unconditionally downloads binary blob

Related Stories