[Pkg-chromium-maint] Bug#786909: chromium: unconditionally downloads binary blob
Christoph Anton Mitterer
calestyo at scientia.net
Fri Jun 19 00:23:18 UTC 2015
On Thu, 2015-06-18 at 23:42 +0100, Steven Chamberlain wrote:
> Upstream have said:
> > This is not "opt-in default". If you do not explicitly opt in
> > (using
> > the "Enable Ok Google" setting in chrome://settings), then this
> > module
> > will not run.
> That suggests to me that security of users was not put at risk,
> they enabled that optional feature. It was likely 'only' a privacy
> concern and Debian policy violation.
I don't think it really matters what upstream claims here, unless
things can be clearly proven by code:
It's very well known that all the big players (Google, Mozilla, etc.)
either voluntarily or forcibly cooperate with organisations like the
NSA, which in turn are notoriously known for trying to attack and hack
into any system, legally or not.
Especially the fact that they don't simply distribute the blob as part
of their bundle but download it, makes it IMHO highly suspicious (yeah,
of course as with Mozilla there's the good excuse of "patent reasons"),
as this could enable an attacker to selectively distribute good/bad
versions of the blob to certain users, thereby making it basically
impossible to ever detect this.
> May I ask boldly, is NaCl a legitimate feature of a Debian package in
> 'main'? I'm reminded of the FSF's John Sullivan speaking at
> about the DFSG iceweasel browser offering to install non-free
> AIUI NaCl's only purpose is to execute compiled, most likely non-free
> this seems an order of magnitude worse).
Browsers generally have really become a security disease... :-/
> I also propose more QA within Debian to find applications phoning
> which could have been detected in this case within something like the
> autopkgtest framework and simply opening a page on a local webserver.
"phoning home" and (down)loading + executing (possibly malicious) blobs
are IMHO two different things.
The former is just a privacy issue (which may or may not be a security
issue as well)... and unfortunately we have already so many packages
doing this (especially many cases where this behaviour is all but
obvious), that I don't see any chances to really solve these privacy
issues without a concentrated effort; and actually, in most cases where
I've already reported such issues I experienced modest to strong
resistance by the respective maintainers and/or upstream.
> Sorry, if you feel this is off-topic for the bug log, please take it
> an appropriate list but preferably keep me in Cc: if you do.
I've already thought about CCing d-d, but to be honest,... I don't
expect that anything would come out from a broader discussion...
security seems to be only tertiary priority in Debian, at least in
several fields (and no, I explicitly do not refer to the Security Team
> The bug made it to Hacker News, so that has been accomplished now
> to some extent.
Well and I've noticed it also mentioned on the cryptography mailing
list and some openbsd lists... and yet...
- still no DSA (or something like that)
- still no concentrated effort at the Debian level to pro-actively work
against such sources that include or more or less secretly download
blobs (I guess it should be obvious that this cannot be the
responsibility of one single person like Michael, and that my criticism
isn't targeted towards him)
- and sadly, as it seems, further, very silently handled cases:
chromium-browser (43.0.2357.124-1) unstable; urgency=medium
* Remove more sourceless files.
Having this popped up at some news sites is basically useless if no
measures are taken.
> Thanks Chris for speaking up about this.
Well it wasn't me who noticed this particular incident of a compromise,
thanks go to Yoshino Yoshihito
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5313 bytes
Desc: not available
More information about the Pkg-chromium-maint