Re: [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  wrote:

> On Oct 29, 2016 12:52 PM, "Yawning Angel" 
> wrote:
> >
> > On Sat, 29 Oct 2016 11:51:03 -0200
> > Daniel Simon  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


pgpHFc_oU8BQF.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Tom Ritter]

On Oct 29, 2016 12:52 PM, "Yawning Angel"  wrote:
>
> On Sat, 29 Oct 2016 11:51:03 -0200
> Daniel Simon  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.

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

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

[Ximin Luo]

libc is dynamically linked so one distribution-level upgrade will fix one libc 
problem. As opposed to having to rebuild every single program and trying to 
ship that to users in a huge update. The former is less complex.

Statically linking shifts the burden of tracking and fixing security bugs, away 
from the maintainers of that library who know it best, onto the program that 
does the static linking. Big development teams like Google can handle this 
responsibility and expend the extra cost needed to make it work. Most other 
projects cannot. Also many people, such as yourself, don't even seem to be 
aware in this fundamental shift in responsibility and development costs. This 
is quite dangerous and naive.

Ivan Markin:
> Yawning Angel:
>> Having to rebuild the browser when the libc needs to be updated seems
>> terrible as well.
> 
> Why is it terrible?
> Using static linking drastically reduces overall *complexity*
> (~1/security). If you do use libc code in your stuff then it's a part of
> this stuff.  If there is a bug in libc - just rebuild your broken
> software. It either works or not. Doing dynamic linking is leaving it in
> superposition state.
> 
> I consider having the browser that builds for >30m is way more terrible.
> 
> From
> https://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/
> :
> 
>> I prefer static linking:
> 
>> Executing statically linked executables is much faster, because there
>> are no expensive shared object lookups during exec().
>>

Who cares?

>> Statically linked executables are portable, long lasting and fail
>> safe to ABI changes -- they will run on the same architecture even in
>> 10 years time. Never expect errors like
>> /lib/ssa/libstdc++.so.6:version 'GLIBCXX_3.4.4' not found again.
>>

When was the last time someone got this error? Like, 1992?

>> Statically linked executables use less disk space. Most executables
>> use only a small subset of the functions provided by a static library
>> -- so there is absolutely no reason to link complete static libraries
>> into a static executable (e.g. spoken for a hello_world.c you only
>> need to link vprintf statically into the executable, not the whole
>> static libc!). The contrary is true for dynamic libraries -- you
>> always use the whole library, regardless what functions you are
>> using.
>>
>> Statically linked executables consume less memory because their
>> binary size is smaller and they only map the functions they depend on
>> into memory (contrary to dynamic libs).
>>

Go and dynamically vs statically link libc to a "hello world" program right now 
and tell me what the size is.

>> The reason why dynamic linking has been invented was not to decrease
>> the general executable sizes or to save memory consumption, or to
>> speed up the exec() -- but to allow changing code during runtime --
>> and that's the real purpose of dynamic linking, we shouldn't forget
>> that.
> 

This guy is rewriting history. It sounds like he's talking about dlopen / 
dynamic loading, which is not the same thing as dynamic linking.

Please do some research before believing random shit on the internet.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Ivan Markin]

Yawning Angel:
> Having to rebuild the browser when the libc needs to be updated seems
> terrible as well.

Why is it terrible?
Using static linking drastically reduces overall *complexity*
(~1/security). If you do use libc code in your stuff then it's a part of
this stuff.  If there is a bug in libc - just rebuild your broken
software. It either works or not. Doing dynamic linking is leaving it in
superposition state.

I consider having the browser that builds for >30m is way more terrible.

From
https://wayback.archive.org/web/20090525150626/http://blog.garbe.us/2008/02/08/01_Static_linking/
:

> I prefer static linking:

> Executing statically linked executables is much faster, because there
> are no expensive shared object lookups during exec().
> 
> Statically linked executables are portable, long lasting and fail
> safe to ABI changes -- they will run on the same architecture even in
> 10 years time. Never expect errors like
> /lib/ssa/libstdc++.so.6:version 'GLIBCXX_3.4.4' not found again.
> 
> Statically linked executables use less disk space. Most executables
> use only a small subset of the functions provided by a static library
> -- so there is absolutely no reason to link complete static libraries
> into a static executable (e.g. spoken for a hello_world.c you only
> need to link vprintf statically into the executable, not the whole
> static libc!). The contrary is true for dynamic libraries -- you
> always use the whole library, regardless what functions you are
> using.
> 
> Statically linked executables consume less memory because their
> binary size is smaller and they only map the functions they depend on
> into memory (contrary to dynamic libs).
> 
> The reason why dynamic linking has been invented was not to decrease
> the general executable sizes or to save memory consumption, or to
> speed up the exec() -- but to allow changing code during runtime --
> and that's the real purpose of dynamic linking, we shouldn't forget
> that.

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