mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: Tom Ritter <tom@ritter.vg>
Cc: tor-dev@lists.torproject.org, musl@lists.openwall.com
Subject: Re: Re: [tor-dev] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure
Date: Sat, 29 Oct 2016 23:59:33 +0200	[thread overview]
Message-ID: <20161029215933.GD5749@port70.net> (raw)
In-Reply-To: <CA+cU71m4FSEVR1_dKq5jLs8DTcvECTKjiUYQupfm1hiVgiLc8w@mail.gmail.com>

* Tom Ritter <tom@ritter.vg> [2016-10-29 09:39:54 -0500]:
> On May 9, 2016 9:15 AM, "Daniel Simon" <ddanielsimonn@gmail.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.



      reply	other threads:[~2016-10-29 21:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09 14:15 Daniel Simon
     [not found] ` <CAPWP2JMcsTz2qh6xkYuRKj2M7=DF4cGM0DbO8GSWX930=SsqOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-29 13:51   ` Daniel Simon
     [not found]     ` <CAPWP2JNevbdXZwex+oU82uDn46u38fcmcBUaj0bqwo-Ry6---A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-29 13:54       ` Jessica Frazelle
2016-10-29 14:39   ` Tom Ritter
2016-10-29 21:59     ` Szabolcs Nagy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161029215933.GD5749@port70.net \
    --to=nsz@port70.net \
    --cc=musl@lists.openwall.com \
    --cc=tom@ritter.vg \
    --cc=tor-dev@lists.torproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).