[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Indirect Tor question
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