[tor-relays] running Tor relay live with AddressSanitizer

[starlight.2014q2 at binnacle.cx]

>I'm sold on integrating AddressSanitizer into Tor
>as a compile-time option.  I've got a ticket for
>doing so #11477
>(https://trac.torproject.org/projects/tor/ticket/11477).
>I've uploaded your patch there, and am looking
>into how to better integrate it.  If you could
>make sure that the code _I_ have successfully
>builds Tor with AddressSanitizer when you
>configure --enable-compiler-hardening, that would
>rock.

Hi Nick,

I'm glad others find the idea interesting
--just saw your post so sorry for the
delayed reply.

The patch is half-baked and needs work to
make it properly portable and to open the
stdxxx files only when appropriate.  I'll
try to find some time to improve it.

I tried having 'tor' umount the /proc
file system but that does not work inside
a chroot jail.  So all the relay process
can do is issue the AS call to cache
and close the address map and the
'umount' must be handled by the start
script.

I learned that AS disables core files
separately from the Linux setting via
an environment variable and that this
may be a good idea due to the huge size
of memory under AS.  Even if the core
is written as a sparse file (which I
think it is), the kernel seemed to spend
a ridiculous amount of time scanning
for populated pages the one time I tried
it.  However I run an old (but minimized
and security-patched) kernel that may
not be the most efficient w/r/t sparse
core file generation.

>(If you like sandboxes, and Linux, you might also
>like to try the seccomp2 sandbox code, once Tor
>0.2.5.4-alpha is out. It's present in Tor
>0.2.5.3-alpha, but it's kind of buggy.)

secomp2 is excellent, but I'll wait
till it's further along.  I can take
only limited quantities of bleeding-
edgedness.

>Also, see bug #11232
>(https://trac.torproject.org/projects/tor/ticket/11232)
>for the stuff I found running under
>AddressSanitizer and ubsan already.

thank you, I'll take a look

Sadly I found that AS only catches Heartbleed
if the attacker reads past the end of
the 17kb heap allocation that goes with
the vulnerable code, even when 'openssl'
is fully compiled with AS active.
No doubt AS is Valgrind on steroids,
but it doesn't catch improper memory
accesses if the memory touched is
"legal".