Re: [tor-talk] Indirect Tor question

[Nathan Suchy <theusernameiwantistaken@xxxxxxxxx>]

The only secure thing is Tor Tails booted from USB.

Sent from my Android so do not expect a fast, long, or perfect response...
On Sep 9, 2013 11:37 AM, "adrelanos" <adrelanos@xxxxxxxxxx> wrote:

> Speaking as a maintainer of Whonix...
>
> Before answering this, there is some prerequisite knowledge. There is a
> difference between:
> - Free Software and free software
> - Open Source and open source
>
> When I am using capitalized Open Source, I am referring to OSI approved
> [1] licenses (by the Open Source Initiative). When I am using
> capitalized Free Software, I am referring to FSF approved [2] licenses
> (by the Free Software Foundation).
>
> I try to prevent using the terms "open source" (which could refer to,
> you can get the source code, perhaps for no charge) and free software.
> The terminology is seriously messed up, but that's not my fault and no
> one is listening to me.
>
> Praedor Atrebates:
> > In light of the recent revelations of how the NSA has broken commercial
> > software all over the place, I wonder about the security of Oracle's
> > VirtualBox VM software used by Whonix (and other?) tor-based anonymity
> > systems.
>
> We're probably all hosed anyway. Already for other reasons, backdoors in
> plain source code. (I will address the concern of about being
> non-opensource mail below.) Another reason is, when it comes to C and
> C++ code, even in the source code you can add subtle, difficult to spot
> backdoors. And I quote Ken Thompson:
>
> "The moral is obvious. You can't trust code that you did not totally
> create yourself. (Especially code from companies that employ people like
> me.) No amount of source-level verification or scrutiny will protect you
> from using untrusted code. In demonstrating the possibility of this kind
> of attack, I picked on the C compiler. I could have picked on any
> program-handling program such as an assembler, a loader, or even
> hardware microcode. As the level of program gets lower, these bugs will
> be harder and harder to detect. A well installed microcode bug will be
> almost impossible to detect." [3]
>
> Solution?
> 1) Let's ditch decades of effort in writing C code.
> 2) Create an operating system with minimal C code.
> 3) Freeze the C code base. Only allow most critical changes.
> 4) Re-implement all other software in higher level languages. Accept the
> performance penalty or wait for faster hardware.
> 5) Also somehow get trustworthy, backdoor-free hardware. [Really Hard (tm)]
> I am not in position to suggest such changes.
>
> > A large portion of VirtualBox is open source but some
> > libraries used are of different licenses...so perhaps somewhere in those
> > non-opensource libs lay an NSA backdoor?
>
> To my knowledge, VirtualBox does not include portions where no source
> code is available for download.
>
> VirtualBox is in Debian contrib, because it requires a non-free
> (according to Debian DFSG [4] and FSF).
>
> The openwatcom compiler is considered non-free because it's under the
> "Sybase Open Watcom Public License version 1.0". FSF says
>
> "This is not a free software license. It requires you to publish the
> source code publicly whenever you “Deploy” the covered software, and
> “Deploy” is defined to include many kinds of private use." [5]
>
> I think Debian also does not use openwatcom compiler, because that
> compiler is not in Debian due to packaging difficulties. [6]
>
> According to the Debian VirtualBox license file [7], "Upstream provides
> pre-built BIOS images which is used instead."
>
> There is also a VirtualBox bug report "Compiling BIOS requires Open
> Watcom compiler" [8], which won't be fixed, but still contains
> interesting information. It says,
>
> "By the way, we provide alternative sources (assembly) of the components
> that normally get built with OpenWatcom, so VirtualBox can be built
> without it. There is nothing missing, we even use them ourselves when
> build the Solaris distribution of VirtualBox. For some reason this seems
> not to be sufficient for all distros." [9]
>
> I don't know if the Debian VirtualBox license file refers to this
> assembly. The thing Debian (rightly so) complains about might be, that
> it's not nicely-commented and formatted assembly source code, but
> assembly binary code?
>
> Anyhow. Realistically, lets assume it was nicely-commented and formatted
> assembly source code. I like to refer back to what I wrote above subtle
> backdoors in plain source code.
>
> Your concern is a valid one. For too long, the rumor, that Open Source
> provides strong security and prevents backdoors has been spread.
>
> There is also just another issue. A non-deterministically build
> operating systems.
>
> Open Source does not automagically prevent backdoors [12], unless the
> user creates its own binaries from source code itself. The ones who
> compile, upload and distribute (also the webhost) the binaries could add
> a backdoor without publishing the backdoor code. Nothing prevents one to
> claim, that a certain binary has been build from a clean source code,
> while the binary was actually build by the source code plus the backdoor
> code. Also the ones who may have infected the build machine with a
> backdoor are in position to add a backdoor without the distributor being
> aware of it. Deterministic builds can detect backdoors. For more
> information on deterministic builds and why this is important, see:
> - liberationtech mailing list: Deterministic builds and software trust [13]
> - gitian.org [14]
> - Quote Mike Perry: Current popular software development practices
> simply cannot survive targeted attacks of the scale and scope that we
> are seeing today. Source: Deterministic Builds Part One: Cyberwar and
> Global Compromise [15]
> - Debian wiki about their progress and development efforts to implement
> Reproducible Builds [16]
>
> That's why I said, we're hosed anyway. Against an adversary with as much
> resources as are available to the NSA, Open Source security is fatally
> failing.
>
> > I'm wondering about any and all similar tor-based systems wherein there
> > is ANY portion that is not opensource.
>
> Scrutiny is a good thing. I suggest using the vrms tool to find non-free
> software. [10] [11] Parts of this non-free software may come without
> source code being available. From a quick curious look into the Tails
> source code greping for "nonfree", I found "firmware-linux-nonfree".
>
> There may be more good reasons to add such packages than against adding
> such packages. (Because not adding those may result in such poor
> hardware support, that there aren't enough users in the first place to
> even theoretically provide anonymity.)
>
> The development version of Whonix (we'll probably make a new release
> soon) includes a check using vrms (while building from source code),
> which provides safety against installing non-free software.
>
> (Tails aiming to be run on hardware may not be so easily be able to drop
> all non-free packages. It's much easier for Whonix when aiming at
> Virtual Machines - I am not saying this solves the problem - it leaves
> the user alone with the decision to install such non-free packages on
> the host.)
>
> [1] http://opensource.org/licenses
> [2] http://www.gnu.org/licenses/license-list.html
> [3] http://cm.bell-labs.com/who/ken/trust.html
> [4] https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines
> [5] https://www.gnu.org/licenses/license-list.html#Watcom
> [6] http://bugs.debian.org/376431
> [7]
>
> http://ftp-master.metadata.debian.org/changelogs//contrib/v/virtualbox/virtualbox_4.2.16-dfsg-2_copyright
> [8] https://www.virtualbox.org/ticket/12011
> [9] https://www.virtualbox.org/ticket/12011#comment:3
> [10] http://packages.debian.org/vrms
> [11] https://en.wikipedia.org/wiki/Vrms
> [12] https://en.wikipedia.org/wiki/Backdoor_%28computing%29
> [13]
> https://mailman.stanford.edu/pipermail/liberationtech/2013-June/009257.html
> [14] http://gitian.org/
> [15]
>
> https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise
> [16] https://wiki.debian.org/ReproducibleBuilds
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsusbscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsusbscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk