[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1434674965.4822.39.camel@scientia.net>
Date: Fri, 19 Jun 2015 02:49:25 +0200
From: Christoph Anton Mitterer <calestyo@...entia.net>
To: Michael Gilbert <mgilbert@...ian.org>
Cc: 786909@...s.debian.org, oss-security@...ts.openwall.com
Subject: Re: Bug#786909: chromium: unconditionally downloads binary blob
On Thu, 2015-06-18 at 20:19 -0400, Michael Gilbert wrote:
> Except that the actual contents of the downloaded files in many ways
> do not actually matter. Those files are nacl executables, which are
> sandboxed in any nacl-enabled chromium, so barring a sandbox escape
> included in the files, this is functionally the same as visiting any
> nacl website (less the fact that hotword automatically gets
> microphone
> permission, which itself is worth independent critique).
I never really understood why browser need to be more and more like
complete operating systems, taking control over hardware which is
simply not their belonging...
If people want to voice/video conferencing, then they should need to
start some locally installed software for just that purpose.
But maybe I'm just too old-fashioned and don't want to have everything
run on the web or in the cloud. :-(
> Additionally, the Debian packages are intentionally built with nacl
> disabled (in fact not built at all). So, at least on Debian, even if
> the downloaded files were in fact malicious, without a nacl
> interpreter present, there is absolutely no way to trigger the
> badness.
Definitely good news...
But my primary point was more that this should simply not happen...
cause in another case, we might not have had that safety of having nacl
not even available.
As I've mentioned, we've had the same issue already with Firefox which
downloaded OpenH246 and which (AFAIR) was actually loaded.
In principle, all code which is not manually
downloaded/compiled/executed by the user should enter a Debian box
*only* via the package management system.
> Maybe now it's clear that a meaningful conversation at the time would
> have preempted the ensuing misinformation campaign.
Well it wasn't me who posted this news to several other places,...
> I simply do not follow the logic leading to this conclusion. How
> does
> engaging in discussion lead to any specific problem being ignored
> exactly?
Well, discussing things at oss-security doesn't have any direct effect
on Debian, right?
Discussing/reporting things directly at upstream is mostly just a waste
of time, at least when it comes about "meta" security issues; just look
at the Mozilla bugtracker for issues reported by me.
And unfortunately, the same applies largely to Debian itself. You may
remember several discussions I've ignited on d-d about such higher
level security issues,... like the "downloader packages", or the far
too high validity times of Release files.
> Anyway, if some incredibly basic homework had been done, you could
> have convinced yourself of the non-issue nature of this problem,
> rather than engaging in unfounded speculation.
I think practically it's extremely time consuming to really confirm
whether such code was loaded or not, especially when one is not
familiar with the code base, which I'm not in the case of Chromium.
And even if that code was just downloaded (but not executed) I still
think it's far from ideal.
configure-options may accidentally change, as may the download code
itself - simply not having any such functionalities in the code is
probably safer than having it just disabled and/or being simply a bit
lucky as we apparently were in this case.
> That is exactly what Debian unstable is for
Phew,... realistically, many people use sid for their normal desktop
systems...
> Well, it is out there now [0,1], unfortunately with a huge amount of
> misinformation.
My apologies, if you feel that this would fall into my
responsibility... as this wasn't my intention (otherwise I'd have CCed
it to d-d).
Personally I think that you as maintainer(s) should feel the least
responsible for this,... it's rather upstream who should need to
reconsider "some things"; and if they got a bit attention now, than
this may not be the biggest harm.
As said before, my main point is the question what we can do to prevent
such cases in the future.
This time, nothing might have gotten executed,... and the code (likely)
wouldn't have been malicious.
Next time it may look different.
Best wishes,
Chris.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5313 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
