Tor hardening at compile time

Sat May 8 11:38:34 UTC 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jacob,

FYI, I have been compiling tor with these hardening features using the
gcc compiler that Magnus and I hacked up and are now trying to get
migrating into Gentoo.  The goodies are in Gentoo overlays.  The ebuilds
are at

http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-development.git;a=summary

The patchset against gcc is at

http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-gccpatchset.git;a=summary

The only difference is that I used stack-protector, whereas you're using
stack-protector-all, which is possibly better.

Anyhow, running and dissecting the resulting binaries/libraries, I have
*never* encountered any issues with gcc-4.*  The only issue was with
gcc-3.4.6 which is already reported at
https://trac.torproject.org/projects/tor/ticket/1060.  We've pretty much
abandoned hardened gcc-3.4.6 anyhow at hardened Gentoo.

So, I vote for putting the patch master, for whatever that's worth.

Anthony G. Basile, Ph.D.
Chair IT, D'Youville College
Buffalo NY 14201
(716) 829-8197

On 05/07/2010 09:15 AM, Jacob Appelbaum wrote:
> Hi,
> 
> I've pushed a new git branch 'compileTimeHardening' out to my git repo.
> I've also attached a patch for those that are git adverse. Either way,
> apply the patch to your current Tor master sources and you should be in
> good shape.
> 
> You can use it like so:
> ./autogen.sh && ./configure --enable-gcc-warnings --enable-gcc-hardening
> --enable-linker-hardening && make && sudo make install
> 
> The end result on Debian Lenny is a slightly hardened build when checked
> with checksec.sh[0].
> 
> This is weasel's build on my x86 machine:
> RELRO           STACK CANARY      NX            PIE
>    Partial RELRO   Canary found      NX enabled    PIE enabled
> 
> This is a build with my new options on the same machine:
> RELRO           STACK CANARY      NX            PIE
> Full RELRO      Canary found      NX enabled    PIE enabled
> 
> This is a build without my new options on the same machine:
> RELRO           STACK CANARY      NX            PIE
> No RELRO        No canary found   NX enabled    No PIE
> 
> This seems like a useful improvement for people building from source.
> 
> The gcc hardening flag works on Mac OS X. The linker hardening is
> specific to the ELF binary format and does not work on Mac OS X. So on
> Mac OS X, only use '--enable-gcc-hardening' and not
> '--enable-linker-hardening' for your builds.
> 
> Checksec doesn't work on Mac OS X. It does appear to be possible to
> check if a binary has a stack canary by doing the following (Using Mac
> OS X 10.6.3 here):
> 
> 	nm /bin/ls | grep "chk_guard"
> 
> You should see something like this:
> 
> 	U ___stack_chk_guard
> 
> Also, you can check by looking for the following with otool on Mac OS X:
> 
> 	otool -tvV /bin/ls | grep "___stack_chk_fail"
> 
> You should see something like this:
> 
> 	00004bf7        calll   0x00005468      ; symbol stub for:
> ___stack_chk_fail
> 
> If you look at /Applications/Vidalia.app/Contents/MacOS/tor, you will
> not see those protections at the moment. I think we can improve our
> shipping Mac OS X binaries by enabling these protections. The PIE
> protections won't really matter until Apple fixes their platform
> (perhaps in 10.7?!); still it's nice to be ready and this patch provides
> that too.
> 
> It appears that FORTIFY_SOURCE is on by default on Mac OS X. We don't
> currently build Tor on Mac OS X with stack canaries though, so we're
> improving Tor's security on Mac OS X. It may not be possible to do this
> for all versions of Mac OS X - I suspect that Apple may disable some or
> all protections to make a binary more compatible with different Mac OS X
> versions.
> 
> It would be useful to get some extra testing on other platforms; is
> anyone working with Windows building and interested in testing this? I
> also left a comment in the patch for hardening flags that would be
> useful with a non-gcc compiler on Windows.
> 
> There is some performance cost to running Tor with these security
> enhancements. Debian already runs with most of the run time checks and
> the relays on Debian appear to be just fine. The only real enhancement
> for Linux systems is a startup time cost to gain protection from GOT/PLT
> overwrites (if you're already using Weasel's packages).  If you're
> merely building from source on any of the supported platforms, it's a
> huge gain.
> 
> I think this option should be enabled by default at some point in the
> future but probably not until we have a reasonably exhaustive list of
> information for our major platforms. After we have a little testing from
> Tor developers, I'll ask on or-talk for some testers.
> 
> It would be nice to have it merged into master as an optional option
> soon though. Roger seemed to think this was a fine idea. I think it may
> encourage people to try it out and to help us decide if it's worth
> applying as a build default.
> 
> All the best,
> Jacob
> 
> [0] http://www.trapkit.de/tools/checksec.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvlTToACgkQl5yvQNBFVTUXcACeJuuQUyP+zDoKop2cG4XD6/On
eSQAnRuFOXGRHxA4YL3eXD83yKk4/LRH
=fv2J
-----END PGP SIGNATURE-----