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

[Yawning Angel]

On Sun, 30 Oct 2016 15:19:59 -0500
Tom Ritter <tom at ritter.vg> wrote:

> On Oct 29, 2016 12:52 PM, "Yawning Angel" <yawning at schwanenlied.me>
> wrote:
> >
> > On Sat, 29 Oct 2016 11:51:03 -0200
> > Daniel Simon <ddanielsimonn at gmail.com> wrote:  
> > > > 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.  
> >
> > This adds a new security issue of "of all the things that should
> > have ASLR, it should be libc, and it was at one point, but we
> > started statically linking it for some stupid reason".  
> 
> If this is accurate, that statically linking will enable pre-built rop
> chains because libc is at a predictable memory address, I would
> strongly oppose it for this reason alone.
> 
> It would be a major step backwards in security.

The right thing *might* happen, if you build everything with -fPIE
(Tor Browser does this), for "libc symbols being in consistent locations
relative to the randomized base address of the executable" definitions
of "right thing".

This is subtly different from "libc symbols are at consistent locations
relative to the randomized base address of the library, for that exact
copy of libc", when using a dynamically linked libc.

Life is a lot better with selfrando, so in practice my objections on
this ground mostly go away in the hardened build, since it applies load
time randomization to all the functions (RANDOMIZE ALL THE THINGS).

All that said.... I'm still not convinced why "the user may use a
different glibc than other users" on it's own is a compelling reason to
ship a statically linked libc:

 1) Tor Browser pulls in lots of other things from the host system,
    some unconditionally (X11, Gtk+), some depending on availability
    (GNOME, libthai, etc).

    Only fixing libc seems like it doesn't help much (and I suspect
    that glibc version diversity isn't that large to begin with).  I
    sincerely doubt that the Tor Browser developers want to be in the
    business of compiling Xorg, Gtk+ or $deity help them, GNOME.

 2) I don't see why this needs to be "statically linked".  Tor Browser
    ships other libraries as dependencies (libevent, openssl,
    libstdc++), and unless libc is magically special, it could be
    shipped as yet another shared library.

    In particular, there is no performance gain to be had by statically
    linking things because Tor Browser is built -fPIE.

 3) Regarding portability, I'm not sure I understand "The Tor Browser
    Bundle can't be run on systems that don't use glibc, making it
    unusable due to different syscalls" argument.  System calls are
    provided by the kernel, and have nothing to do with libc.

    Assuming the author meant "ABI compatibility issues"...

    If there are bugs that arise from "a Tor Browser component
    assumes/requires non-standard glibc behavior at the source level"
    then that should be fixed.  Most of these things are probably
    upstream Firefox issues.

    As far as runtime compatibility goes, this is a lot of work
    (initially and continuing) to support the fraction of the userbase
    that's using a rather non-standard libc.  I do not know if the
    Browser developers have such resources.

nb: Not a browser developer, they will chose to do what they wish.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161031/bf78960f/attachment.sig>