From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10687 Path: news.gmane.org!.POSTED!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general,gmane.network.tor.devel 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 Message-ID: <20161029215933.GD5749@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1477778407 24683 195.159.176.226 (29 Oct 2016 22:00:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2016 22:00:07 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) Cc: tor-dev@lists.torproject.org, musl@lists.openwall.com To: Tom Ritter Original-X-From: musl-return-10700-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 30 00:00:03 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1c0bfE-00043G-Dl for gllmg-musl@m.gmane.org; Sat, 29 Oct 2016 23:59:44 +0200 Original-Received: (qmail 1976 invoked by uid 550); 29 Oct 2016 21:59:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1958 invoked from network); 29 Oct 2016 21:59:45 -0000 Mail-Followup-To: Tom Ritter , tor-dev@lists.torproject.org, musl@lists.openwall.com Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:10687 gmane.network.tor.devel:9358 Archived-At: * Tom Ritter [2016-10-29 09:39:54 -0500]: > On May 9, 2016 9:15 AM, "Daniel Simon" 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.