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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ