Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chromium unconditionally downloads binary blob

bugs.debian.org

Post reply on HN
Print view View original

31–40 of 180 posts

Re: Chromium unconditionally downloads binary blob

#31

Post by simoncion »

espadrine wrote: post #29
mseebach wrote: post #26

Earlier quoted context omitted.

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.

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.

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.

Re: Chromium unconditionally downloads binary blob

#32

Post by vbezhenar »

roel_v wrote: post #27
luso_brazilian wrote: post #24

Earlier quoted context omitted.

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 inci…

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

You can't realistically audit binary blob. But you can audit source code. So if download is protected by the digital signature, it's OK.

Re: Chromium unconditionally downloads binary blob

#33

Post by mseebach »

espadrine wrote: post #29
mseebach wrote: post #26

Earlier quoted context omitted.

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.

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.

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.

Re: Chromium unconditionally downloads binary blob

#34

Post by kiallmacinnes »

belorn wrote: post #28

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.

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.

Re: Chromium unconditionally downloads binary blob

#35

Post by rockdoe »

simoncion wrote: post #31
espadrine wrote: post #29

Earlier quoted context omitted.

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.

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.

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.

Re: Chromium unconditionally downloads binary blob

#36

Post by rockdoe »

mseebach wrote: post #33
espadrine wrote: post #29

Earlier quoted context omitted.

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.

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.

Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.

Re: Chromium unconditionally downloads binary blob

#37

Post by belorn »

simoncion wrote: post #30
belorn wrote: post #28

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.

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 w…

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.

Re: Chromium unconditionally downloads binary blob

#38

Post by morganvachon »

dtech wrote: post #18
BRG_12 wrote: post #5

Earlier quoted context omitted.

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.

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.

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

Re: Chromium unconditionally downloads binary blob

#39

Post by pbhjpbhj »

dtech wrote: post #18
BRG_12 wrote: post #5

Earlier quoted context omitted.

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.

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.

>this is like calling someone a murderer because he went to the same high school as a murderer //

I'd say a closer analogy would be because he had the same blood splatter pattern on his clothes as a murderer. But neither is a useful analogy they're just biased by our perspective on Google.

Re: Chromium unconditionally downloads binary blob

#40

Post by IshKebab »

rockdoe wrote: post #36
mseebach wrote: post #33

Earlier quoted context omitted.

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.

Firefox doesn't support NacCl, Mozilla has show no intention of integrating it and they even criticized the technology.

Yeah but that's because Mozilla loves javascript and NaCl provides a working alternative.
Post reply on HN