[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 29 Oct 2016 23:59:33 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Tom Ritter <tom@...ter.vg>
Cc: tor-dev@...ts.torproject.org, musl@...ts.openwall.com
Subject: Re: Re: [tor-dev] [Proposal] A simple way to make
Tor-Browser-Bundle more portable and secure
* Tom Ritter <tom@...ter.vg> [2016-10-29 09:39:54 -0500]:
> On May 9, 2016 9:15 AM, "Daniel Simon" <ddanielsimonn@...il.com> wrote:
> > How it's currently done - The Tor Browser Bundle is dynamically linked
> > against glibc.
> >
> > Security problem - The Tor Browser Bundle has the risk of information
> > about the host system's library ecosystem leaking out onto the
> > network.
>
> So I'm not a libc expert, would you be willing to unpack this for me and
> explain what sorts of data can leak and how? It seems to me that it would
> require some high amount of attacker control - control of arguments to
> functions, inspecting memory layout, or code execution...
>
if one rebuilds tor from source then there is a chance that
the final binary has subtly different behaviour than the
official tor bundle which may be observable via network
communication allowing the identification of the user, which
may break anonymity guarantees, simply because different
toolchain is used.
the same reasoning applies to different underlying hardware
or kernel or indeed library dependencies that may vary among
users (e.g. javascript Math.sin may call libc sin and different
versions of glibc have different precision result).
i don't know how much of this is a concern for the tor
project and it is hard to tell how much static linking
would improve things for linux users as the os can probably
be fingerprinted anyway.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
