9 ms·

Chromium unconditionally downloads binary blob

550 points by fractalcat 11y ago

AndrewDMcG 11y 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 https://code.google.com/p/chromium/issues/detail?id=491435
- jug 11y 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.
  - rockdoe 11y ago
    That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
    - mseebach 11y ago
      It's really hard to create vendor lock in on a feature nobody uses. But even if they did go down that route, NaCl is licensed under BSD, so even Microsoft could add NaCL to IE if they wanted to. That's some pretty weak vendor lock-in.
      - espadrine 11y ago
        Licensing is not the issue. Microsoft could not add NaCL to IE in the same sense that it could not add Firefox' DevTools to IE. It would require a major rewrite and cost tremendous heaps of money.
        simoncion 11y ago
        I've gotta raise an eyebrow on that one. If it's a major rewrite to support a new plugin authoring language, your plugin architecture was a terrible mess to begin with. Given that we're supposed to believe that New Internet Explorer was pretty much a from-the-ground-up rewrite, I can't imagine that their plugin architecture is a terrible mess.
        rockdoe 11y ago
        NaCl isn't simply a plugin architecture. It is effectively the entire Chrome sandbox and large parts of Chrome architecture made available to binary plugins. You aren't pulling it into your project without also pulling in half of Chrome.
        simoncion 11y ago
        According to this [0], NaCl is a Pepper plugin. [1] This would strongly imply that all you'd need to do to use NaCl is to implement PPAPI. Care to point out how I'm wrong about that? [0] https://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Native-Client-NaCl- https://www.chromium.org/nativeclient/getting-started/gettin... [1] Indeed, in a vaguely-recent Chrome, about:plugins has this to say about NaCl: Native Client Name: Native Client Version: Location: /opt/google/chrome/internal-nacl-plugin Type: PPAPI (in-process)
        pilif 11y ago
        the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need. Check https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api for a list of currently supported features. For other browsers to support PPAPI, they'd have to implement all of this, which, btw, also is a moving target that moves forward in lockstep with chrome releases.
        11y ago
        mseebach 11y ago
        Even if that's true (and I share the sibling's skepticism), vendor A's incompetence and poor product quality is not meaningfully described as "lock-in" to vendor B - especially so when there's a readily available vendor C (Firefox) that doesn't share these ills.
        rockdoe 11y ago
        Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.
        IshKebab 11y ago
        Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
        stevehawk 11y ago
        How is NaCl not just "Google's version of ActiveX"
        spot 11y ago
        it's secure and open source.
        stevehawk 11y ago
        Nothing is "secure".
        strcat 11y ago
        It's more secure than JavaScript, which is a start. Dropping the need for just-in-time compilation while gaining performance is nice.
        11y ago
  - mortehu 11y 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.
    - jug 11y ago
      It does, and I enjoy mp4 videos and I'm not bothered much by DRM on Netflix either, but should a component like NaCl implying a binary blob be part of an open source software.. by default? Feels weird to have it included with Chromium by default. Weren't Chrome and Chromium originally separated in order to make one compatible with open source distributions, so that this sort of thing would be avoided? A conflict with Debian sounds like a pretty big one.
      - strcat 11y ago
        NaCl doesn't imply proprietary any more than a JavaScript engine does. The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. It's not substantially different from a freedom perspective than code compiled to asm.js or just minified JavaScript. Both are usually proprietary and require reverse engineering work to decipher.
        vezzy-fnord 11y ago
        As it's not the "preferred form of the work", I think it is proprietary - same way any object/intermediate or obfuscated code would be.
        rockdoe 11y ago
        >NaCl doesn't imply proprietary any more than a JavaScript engine does http://www.gnu.org/philosophy/javascript-trap.html http://www.gnu.org/philosophy/javascript-trap.html
        diamondlovesyou 11y ago
        > The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. You just described PNaCl, not NaCl. NaCl is architecture specific and already sandboxed (ie the SFI part of NaCl), whereas PNaCl is not.
- dtech 11y ago
  Note that it wasn't an upstream bug per se, they added a build flag to disable it.
- JoshTriplett 11y 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.
rockdoe 11y 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 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.
- kibibu 11y 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?.
- lambada 11y ago
  By 'some' you mean 'one'.
- BRG_12 11y 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.
  - rockdoe 11y 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.
samwillis 11y 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 11y ago
  "Don't worry, it's running as restricted windows user, there is no way it could possibly ever... oh"
  - blfr 11y ago
    Sandboxed unknown code is still better than non-sandboxed unknown code.
    - samastur 11y ago
      Agreed, but it is not the same thing as saying there is no security issue.
  - nadams 11y 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 11y ago
  But it's closed source, which is a criterion that Debian have historically regarded with a very high priority.
longsleep 11y 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/ https://iridiumbrowser.de/
- deleted 11y ago
  [deleted]
- pmontra 11y ago
  I didn't know about Iridium. I'll give it a try.
- mikegioia 11y ago
  I'm running Iridium and this module is loaded, at least "chrome://voicesearch/" loads the same info.
- castell 11y ago
  another one is "Iron browser"
  - mnnsmnn 11y 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 11y ago
    Which is not to be trusted in the slightest
golergka 11y ago
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.
deleted 11y ago
[deleted]
belorn 11y 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.
- simoncion 11y 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.
  - belorn 11y 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.
    - simoncion 11y ago
      It really looks like it uses the normal way to download extensions; the Web Store. I'd be more concerned that the only thing the patch seems to do is not activate the hotword extension. It seems to still download and install it. I mean, maybe I'm wrong here. I think that checking through https://chromium.googlesource.com/chromium/src/+/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/browser/search/hotword_service.cc https://chromium.googlesource.com/chromium/src/+/f269d3b5482... for ENABLE_HOTWORDING is the right thing to do if one wants to understand the change that was made.
zoner 11y ago
Switched to Firefox as the primary browser just to be sure :)
- codazoda 11y 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.
  - icebraining 11y ago
    Firefox's blob is open source, though (OpenH264 is on Github and is BSD-licensed).
  - pgeorgi 11y 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).
  - strcat 11y 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 11y ago
    http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ http://andreasgal.com/2014/10/14/openh264-now-in-firefox/
- nivla 11y 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1172126
kekebo 11y 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 https://code.google.com/p/chromium/issues/detail?id=500922
- jwise0 11y ago
  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 11y 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 11y 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 11y 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 11y ago
Any idea what is the executable doing ?
- strcat 11y 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 11y 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.
- laumars 11y 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 :)
jameshart 11y 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.
- marssaxman 11y ago
  Is this true of Chrome as well? If so, I will never run it again.
  - mynameisvlad 11y 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.
    - marssaxman 11y ago
      It seemed plausible, but I don't know what "NaCl" is, have no familiarity with Chrome internals, and had never heard of this before. Seemed like it was worth checking before making such a decision. I am amazed that Google has repeated Microsoft's mistake with ActiveX - who would think this was a good idea?
  - jameshart 11y ago
    I have bad news for you: Chrome is a binary blob of code from Google that has access to your microphone.
    - metaobject 11y ago
      I wonder if there is a way to monitor whether the mic is being accessed from a program on linux?
lasermike026 11y ago
The only microphone I trust is the one that is not there. How sad.
- iamcurious 11y 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 11y 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 11y 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 11y ago
  >vicinity of the phone What phone? Last I checked this was for the desktop build of Chromium
- hoers 11y ago
  No but a ticket https://code.google.com/p/chromium/issues/detail?id=500922 https://code.google.com/p/chromium/issues/detail?id=500922
- CamperBob2 11y 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_parade2 11y ago
Since these things can be opaque, archlinux updated to disable "hotword": https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=c82e0548218e0398c3788730f3a729d714191d0c https://projects.archlinux.org/svntogit/packages.git/commit/... thanks to the maintainer and the FOSS community in general.
amd_ 11y ago
Not sure why everyone keeps saying "binary blob?", I guess it's similar to when people say "TCP protocol".

550 points by fractalcat 11y 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 https://code.google.com/p/chromium/issues/detail?id=491435

jug 11y 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.
- rockdoe 11y ago
  That's the point. It's strong vendor lock in because NaCl is unadoptable by their competition.
  - mseebach 11y ago
    It's really hard to create vendor lock in on a feature nobody uses. But even if they did go down that route, NaCl is licensed under BSD, so even Microsoft could add NaCL to IE if they wanted to. That's some pretty weak vendor lock-in.
    - espadrine 11y ago
      Licensing is not the issue. Microsoft could not add NaCL to IE in the same sense that it could not add Firefox' DevTools to IE. It would require a major rewrite and cost tremendous heaps of money.
      - simoncion 11y ago
        I've gotta raise an eyebrow on that one. If it's a major rewrite to support a new plugin authoring language, your plugin architecture was a terrible mess to begin with. Given that we're supposed to believe that New Internet Explorer was pretty much a from-the-ground-up rewrite, I can't imagine that their plugin architecture is a terrible mess.
        rockdoe 11y ago
        NaCl isn't simply a plugin architecture. It is effectively the entire Chrome sandbox and large parts of Chrome architecture made available to binary plugins. You aren't pulling it into your project without also pulling in half of Chrome.
        simoncion 11y ago
        According to this [0], NaCl is a Pepper plugin. [1] This would strongly imply that all you'd need to do to use NaCl is to implement PPAPI. Care to point out how I'm wrong about that? [0] https://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics#TOC-Native-Client-NaCl- https://www.chromium.org/nativeclient/getting-started/gettin... [1] Indeed, in a vaguely-recent Chrome, about:plugins has this to say about NaCl: Native Client Name: Native Client Version: Location: /opt/google/chrome/internal-nacl-plugin Type: PPAPI (in-process)
        pilif 11y ago
        the PPAPI is very closely tied to chrome's inner workings and is extremely complicated to implement as, compared to the old plugin api's, it doesn't allow native code any access to the local system. So it needs to provide plugins with all the possible hooks they will ever need. Check https://developer.chrome.com/native-client/c-api https://developer.chrome.com/native-client/c-api for a list of currently supported features. For other browsers to support PPAPI, they'd have to implement all of this, which, btw, also is a moving target that moves forward in lockstep with chrome releases.
        11y ago
      - mseebach 11y ago
        Even if that's true (and I share the sibling's skepticism), vendor A's incompetence and poor product quality is not meaningfully described as "lock-in" to vendor B - especially so when there's a readily available vendor C (Firefox) that doesn't share these ills.
        rockdoe 11y ago
        Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.
        IshKebab 11y ago
        Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
        stevehawk 11y ago
        How is NaCl not just "Google's version of ActiveX"
        spot 11y ago
        it's secure and open source.
        stevehawk 11y ago
        Nothing is "secure".
        strcat 11y ago
        It's more secure than JavaScript, which is a start. Dropping the need for just-in-time compilation while gaining performance is nice.
        11y ago
- mortehu 11y 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.
  - jug 11y ago
    It does, and I enjoy mp4 videos and I'm not bothered much by DRM on Netflix either, but should a component like NaCl implying a binary blob be part of an open source software.. by default? Feels weird to have it included with Chromium by default. Weren't Chrome and Chromium originally separated in order to make one compatible with open source distributions, so that this sort of thing would be avoided? A conflict with Debian sounds like a pretty big one.
    - strcat 11y ago
      NaCl doesn't imply proprietary any more than a JavaScript engine does. The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. It's not substantially different from a freedom perspective than code compiled to asm.js or just minified JavaScript. Both are usually proprietary and require reverse engineering work to decipher.
      - vezzy-fnord 11y ago
        As it's not the "preferred form of the work", I think it is proprietary - same way any object/intermediate or obfuscated code would be.
      - rockdoe 11y ago
        >NaCl doesn't imply proprietary any more than a JavaScript engine does http://www.gnu.org/philosophy/javascript-trap.html http://www.gnu.org/philosophy/javascript-trap.html
      - diamondlovesyou 11y ago
        > The downloaded code is bytecode at an abstraction level a bit below C but quite a bit above assembly. You just described PNaCl, not NaCl. NaCl is architecture specific and already sandboxed (ie the SFI part of NaCl), whereas PNaCl is not.
dtech 11y ago
Note that it wasn't an upstream bug per se, they added a build flag to disable it.
JoshTriplett 11y 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.

rockdoe 11y 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 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.

kibibu 11y 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?.
lambada 11y ago
By 'some' you mean 'one'.
BRG_12 11y 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.
- rockdoe 11y 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.

samwillis 11y 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 11y ago
"Don't worry, it's running as restricted windows user, there is no way it could possibly ever... oh"
- blfr 11y ago
  Sandboxed unknown code is still better than non-sandboxed unknown code.
  - samastur 11y ago
    Agreed, but it is not the same thing as saying there is no security issue.
- nadams 11y 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 11y ago
But it's closed source, which is a criterion that Debian have historically regarded with a very high priority.

longsleep 11y 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/ https://iridiumbrowser.de/

deleted 11y ago
[deleted]
pmontra 11y ago
I didn't know about Iridium. I'll give it a try.
mikegioia 11y ago
I'm running Iridium and this module is loaded, at least "chrome://voicesearch/" loads the same info.
castell 11y ago
another one is "Iron browser"
- mnnsmnn 11y 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 11y ago
  Which is not to be trusted in the slightest

golergka 11y ago

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.

deleted 11y ago

[deleted]

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

simoncion 11y 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.
- belorn 11y 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.
  - simoncion 11y ago
    It really looks like it uses the normal way to download extensions; the Web Store. I'd be more concerned that the only thing the patch seems to do is not activate the hotword extension. It seems to still download and install it. I mean, maybe I'm wrong here. I think that checking through https://chromium.googlesource.com/chromium/src/+/f269d3b548203e217e8c0080c2e22e7ae3efb51e/chrome/browser/search/hotword_service.cc https://chromium.googlesource.com/chromium/src/+/f269d3b5482... for ENABLE_HOTWORDING is the right thing to do if one wants to understand the change that was made.

zoner 11y ago

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

codazoda 11y 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.
- icebraining 11y ago
  Firefox's blob is open source, though (OpenH264 is on Github and is BSD-licensed).
- pgeorgi 11y 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).
- strcat 11y 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 11y ago
  http://andreasgal.com/2014/10/14/openh264-now-in-firefox/ http://andreasgal.com/2014/10/14/openh264-now-in-firefox/
nivla 11y 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1172126

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

jwise0 11y ago
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 11y 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 11y 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 11y 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 11y ago

Any idea what is the executable doing ?

strcat 11y 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 11y 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.

laumars 11y 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 :)

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

marssaxman 11y ago
Is this true of Chrome as well? If so, I will never run it again.
- mynameisvlad 11y 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.
  - marssaxman 11y ago
    It seemed plausible, but I don't know what "NaCl" is, have no familiarity with Chrome internals, and had never heard of this before. Seemed like it was worth checking before making such a decision. I am amazed that Google has repeated Microsoft's mistake with ActiveX - who would think this was a good idea?
- jameshart 11y ago
  I have bad news for you: Chrome is a binary blob of code from Google that has access to your microphone.
  - metaobject 11y ago
    I wonder if there is a way to monitor whether the mic is being accessed from a program on linux?

lasermike026 11y ago

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

iamcurious 11y 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 11y 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 11y 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 11y ago
>vicinity of the phone What phone? Last I checked this was for the desktop build of Chromium
hoers 11y ago
No but a ticket https://code.google.com/p/chromium/issues/detail?id=500922 https://code.google.com/p/chromium/issues/detail?id=500922
CamperBob2 11y 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_parade2 11y ago

Since these things can be opaque, archlinux updated to disable "hotword": https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/chromium&id=c82e0548218e0398c3788730f3a729d714191d0c https://projects.archlinux.org/svntogit/packages.git/commit/... thanks to the maintainer and the FOSS community in general.

amd_ 11y ago

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