[Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Daniel Simon]

Hello.

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.

Portability problem - The Tor Browser Bundle can't be run on systems
that don't use glibc, making it unusable due to different syscalls.

Solution proposed - Static link the Tor Browser Bundle with musl
libc.[1] It is a simple and fast libc implementation that was
especially crafted for static linking. This would solve both security
and portability issues.

What is Tor developers' opinion about this? I personally don't see any
drawbacks and would be interested in discussing this further.

Sincerely,
Daniel

[1] https://www.musl-libc.org/
_______________________________________________
tor-dev mailing list
tor-dev-AQ2JdjIqcwS4QsDJlTKKhWD2FQJk+8+b@public.gmane.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Daniel Simon]

Anyone got further into this?
It would be a joint-project between musl and tor organizations.
Maybe for GSoC 2017 if nobody works on it until then?


On Mon, May 9, 2016 at 11:15 AM, Daniel Simon <ddanielsimonn@gmail.com> wrote:
> Hello.
>
> 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.
>
> Portability problem - The Tor Browser Bundle can't be run on systems
> that don't use glibc, making it unusable due to different syscalls.
>
> Solution proposed - Static link the Tor Browser Bundle with musl
> libc.[1] It is a simple and fast libc implementation that was
> especially crafted for static linking. This would solve both security
> and portability issues.
>
> What is Tor developers' opinion about this? I personally don't see any
> drawbacks and would be interested in discussing this further.
>
> Sincerely,
> Daniel
>
> [1] https://www.musl-libc.org/
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Jessica Frazelle]

[-- Attachment #1.1: Type: text/plain, Size: 1701 bytes --]

There must already be a version of Tor working with musl since there are
Alpine Linux packages for Tor. I'm sure they dynamically link but it's
seems like patching that would be the way to go.

https://pkgs.alpinelinux.org/package/edge/community/x86_64/tor

On Oct 29, 2016 06:51, "Daniel Simon" <ddanielsimonn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Anyone got further into this?
> It would be a joint-project between musl and tor organizations.
> Maybe for GSoC 2017 if nobody works on it until then?
>
>
> On Mon, May 9, 2016 at 11:15 AM, Daniel Simon <ddanielsimonn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
> > Hello.
> >
> > 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.
> >
> > Portability problem - The Tor Browser Bundle can't be run on systems
> > that don't use glibc, making it unusable due to different syscalls.
> >
> > Solution proposed - Static link the Tor Browser Bundle with musl
> > libc.[1] It is a simple and fast libc implementation that was
> > especially crafted for static linking. This would solve both security
> > and portability issues.
> >
> > What is Tor developers' opinion about this? I personally don't see any
> > drawbacks and would be interested in discussing this further.
> >
> > Sincerely,
> > Daniel
> >
> > [1] https://www.musl-libc.org/
> _______________________________________________
> tor-dev mailing list
> tor-dev-AQ2JdjIqcwS4QsDJlTKKhWD2FQJk+8+b@public.gmane.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>

[-- Attachment #1.2: Type: text/html, Size: 2660 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Tom Ritter]

[-- Attachment #1.1: Type: text/plain, Size: 638 bytes --]

On May 9, 2016 9:15 AM, "Daniel Simon" <ddanielsimonn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hello.
>
> 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...

-tom

[-- Attachment #1.2: Type: text/html, Size: 885 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: Re: [tor-dev] [Proposal] A simple way to make Tor-Browser-Bundle more portable and secure

[Szabolcs Nagy]

* 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.