
Chromium unconditionally downloads binary blob - fractalcat
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
======
jimrandomh
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.

~~~
laumars
_> 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 :)

~~~
morganvachon
> 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...](https://en.wikipedia.org/wiki/Android_\(operating_system\)#History)

[2] [http://android-developers.blogspot.com/2008/09/announcing-
an...](http://android-developers.blogspot.com/2008/09/announcing-
android-10-sdk-release-1.html)

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

Fair point, but AFAIK Android was never released as an open source project
until it was Google owned.

 _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._

You were emphasising the wrong part of my sentence. Many proprietary
components that are now part of Google Play Services have existed seperately
for longer than the "Play" brand had:
[https://en.wikipedia.org/wiki/Google_Mobile_Services](https://en.wikipedia.org/wiki/Google_Mobile_Services)

~~~
morganvachon
> Fair point, but AFAIK Android was never released as an open source project
> until it was Google owned.

Since we're both being pedantic here, I never said that it was. :) I believe
the GP did though (the person you were initially replying to, that is).

> Many proprietary components that are now part of Google Play Services have
> existed seperately for longer than the "Play" brand had

You're right, and that's one of the things that bothers me about Android's
reputation for being an "open" or "open source friendly" OS. Yes, AOSP is open
source software (if you leave out the binary blobs necessary for the radios
and GPU to work), but even plain vanilla Android as shipped by Google is far
from open source. Google has steadily been moving towards a closed/locked down
model in many of their projects.

------
spdustin
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
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.

------
belorn
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.

~~~
simoncion
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.

~~~
belorn
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.

~~~
acdha
> Since it doesn't use the normal ways to download extension, I would assume
> it does not use TLS connection

If this was some random enterprise Java app, yes, that would be a reasonable
assumption but you're talking about one of the most heavily audited codebases
in existence, which has one of the best security teams in the world working on
making TLS stronger and aggressively pinning certificates. Their track record
would merit actually looking at the source rather than simply speculating.

------
Animats
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?

~~~
CamperBob2
_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."

------
AndrewDMcG
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](https://code.google.com/p/chromium/issues/detail?id=491435)

~~~
jug
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.

~~~
mortehu
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.

~~~
cpeterso
Chrome's Flash Player uses PPAPI (Pepper), not NaCl. Pepper Flash is still
running Adobe's native code, not NaCl code.

~~~
rockdoe
So it's using the NaCl sandbox and interface without the bytecode parts?

~~~
cpeterso
As I understand it, NaCl is a Pepper plugin, but Pepper does not rely on NaCl.
Other Pepper plugins are not necessarily using NaCl.

[https://code.google.com/p/nativeclient/wiki/Pepper](https://code.google.com/p/nativeclient/wiki/Pepper)

------
josteink
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.

------
golergka
[https://code.google.com/p/chromium/issues/detail?id=491435](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.

------
jameshart
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.

~~~
marssaxman
Is this true of Chrome as well?

If so, I will never run it again.

~~~
snops
They are sandboxed "machine independent" binary blobs that chrome translates
into the local architecture, see [https://developer.chrome.com/native-
client](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?

~~~
marssaxman
I didn't even know this "native client sandbox" existed! Why the hell should I
trust it, or anything executed inside it?

I'm tentatively willing to believe that Chrome is probably not trying to pwn
my box, because I don't think Google has a compelling reason to do that which
would outweigh the flak they would get if they were caught. Allowing them to
run arbitrary compiled executables on my machine, however, would require me to
transitively extend trust to everyone using their technology, and to do that I
would have to be confident that there are not and never will be any security
holes in their sandbox. That is an unlikely proposition to say the least and
therefore I want nothing to do with NaCl.

~~~
fapjacks
In some instances when served with an NSL (or some other mechanism we don't
even yet know about), they can be forced through legal policy to cooperate in
building something that pwns your box. Google's compelling reason is that they
are under the jurisdiction of the American government. Though I share your
tentative belief that Chrome/ium isn't necessarily a "pwn vector" per se, I am
100% willing to believe that they are compelled to cooperate in building some
kind of vector for the NSA.

~~~
grrowl
You say "they" as in Google, but it would be much more effective to persuade a
single developer (and maybe his manager) who can implement such a feature in a
open, transparent way (which would display the standard "recording" icon in
the omnibar) or in a closed, subversive way (like, this).

Basically lean on "Never attribute to malice that which is adequately
explained by stupidity" as much as possible to fly under the radar as long as
possible.

------
kekebo
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](https://code.google.com/p/chromium/issues/detail?id=500922)

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

~~~
hoers
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

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

How sad.

~~~
iamcurious
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.

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

------
fla
Any idea what is the executable doing ?

~~~
strcat
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.

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

~~~
codazoda
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.

~~~
pgeorgi
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).

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

[https://projects.archlinux.org/svntogit/packages.git/commit/...](https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=c82e0548218e0398c3788730f3a729d714191d0c)

thanks to the maintainer and the FOSS community in general.

------
longsleep
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/](https://iridiumbrowser.de/)

~~~
castell
another one is "Iron browser"

~~~
mnnsmnn
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.

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

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

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

~~~
samastur
Agreed, but it is not the same thing as saying there is no security issue.

------
rockdoe
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](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.

~~~
BRG_12
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.

~~~
dtech
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.

~~~
morganvachon
> without any evidence to support it this is like calling someone a murderer
> because he went to the same high school as a murderer.

That's a pretty flawed analogy. If you're going to examine it from a criminal
act point of view, let's really look at it that way. If installing a rootkit
is equivalent to premeditated murder, then the murderer must have motive,
means, and opportunity. Let's take Sony as a good example of a company guilty
of installing a rootkit. Motive: Prevent unauthorized copying of their music
CDs. Means: Rootkit is embedded in the audio CD and uses Windows' Autoplay
feature to install itself. Opportunity: They didn't disclose this rootkit so
anyone who bought a Sony audio CD during that era was vulnerable.

Now, let's look at what we know about this Chromium binary blob silent install
(note I'm not calling it a rootkit, as I agree with you that's taking it a bit
far, but it would theoretically be possible to install one via the same
method). Motive: Google wants to put the same always-listening "feature" on
Chromium installs as well as plain old Chrome. Means: Google writes and
publishes the Chromium source code. Opportunity: Just guessing here, but
Google releases this change without announcing it (otherwise why didn't the
Debian packagers see it right away?).

Now, once again I'm in agreement with you that calling this a rootkit
downloader is a bit much. But what if it had actually been a rootkit, inserted
by Google either intentionally (I don't trust them, but honestly why would
they do something that nefarious?), or without their knowledge or consent
(which would mean they are compromised by an outside actor). That is why this
is such a big deal, and kudos to the Debian team for finding it.

It also bothers me that this binary blob, while not actually a rootkit, did
have the ability to listen to the computer's microphone 24/7 (yes, that is a
"feature" as it is part of Google Now), and can't be audited because there is
no publicly available source code. That's quite a security hole; I recall
discussing all kinds of financial and personal matters with my wife right in
front of our computers. Thankfully they are both desktop machines without
built in microphones, but many people these days use laptops as their main
computer.

To sum up, I don't like it and I think it's a shitty thing for Google to do.
Whether it was intended to be a silent install instead of public knowledge, or
just a major gaffe, remains to be seen.

~~~
mavhc
Seems like the OS should be doing a lot more sandboxing of hardware features.
And is Chromium ever run as root? How could it install a rootkit if not?

~~~
rockdoe
The problem is that a browser does really want access to a whole lot of stuff
as it's almost an OS.

But no, Chromium doesn't run as root afaik, the rootkit stuff is complete
bullshit.

~~~
strcat
The sandbox binary uses setuid root if user namespaces aren't available, but
that's a necessity for making the empty chroot and process/network namespaces
used to sandbox tabs. The layer-2 sandboxing code (seccomp-bpf) doesn't
require anything like that, but they're meant to be complementary (although
both are strict enough that they could act as a meaningful sandbox alone).

~~~
rockdoe
That's really interesting, thanks.

