[tor-relays] running Tor relay live with AddressSanitizer

[starlight.2014q2 at binnacle.cx]

Based on my experience today, I'd say this is
an excellent idea for any Tor relay operator.

Have been running 'tor' on the router since
late November with AddressSanitizer and
it has crashed exactly ONE time:  Today
when someone attempted to apply the
OpenSSL "Heartbleed" attack against
the relay.

I asked the AS devs about removing the
need for mounting /proc in the 'chroot'
jail and it turns out a simple call can
be inserted to close /proc after AS caching
of address maps is complete.  Haven't
created a patch for that yet, but
here is the info

https://code.google.com/p/address-sanitizer/issues/detail?id=237

My current patch to direct sdtout/stderr
to files is attached.

Only downside is that AS does consume
a lot of memory.  After a month it eats
80% of the 2G of RAM on the router.
However it seems to level off there
and cease growing.




At 15:04 10/31/2013 -0500, starlight.2013q4 at binnacle.cx wrote:
>At 18:14 10/24/2013 -0400, starlight.2013q4 at binnacle.cx wrote:
>>Has anyone tried running a live relay with
>>an image built using GCC 4.8 and
>>-fsanitize=address?
>
>Took an initial jab at it by compiling
>just 'tor' with
>
>   CFLAGS = -g -O1 -D_FORTIFY_SOURCE=2 -fstack-protector-all 
>-Wstack-protector -fwrapv --param ssp-buffer-size=1 -fPIE -Wall 
>-fno-strict-aliasing -fsanitize=address -fno-omit-frame-pointer
>
>where the modified or added flags are are
>
>   -O1 -fsanitize=address -fno-omit-frame-pointer
>
>Fired it up and is looking good so far.  CPU
>consumption quite reasonable at below 10%,
>though the relay is capped at 350 Kbytes/sec
>(while spiking to 500+ on a regular basis).
>CPU hardly seems to have increased at all.
>Memory consumption is, of course, up
>substantially with 'tor' swallowing 40%
>of the available 2G.
>
>Patched
>
>   src/common/util.c:finish_daemon()
>
>to direct stdout/stderr to out/err.tor.
>If AS traps-out a violation the reported
>details will be captured.
>
>Had to add 
>
>   libasan.so.0 -> libasan.so.0.0.0
>   libasan.so.0.0.0
>   libstdc++.so.6 -> libstdc++.so.6.0.18
>   libstdc++.so.6.0.18
>
>to the 'chroot' jail.  Surprised to
>see that AS has C++ elements.
>
>Unfortunately AS requires
>
>   /proc/self
>
>for access to address-space map files so
>
>   mount -o bind /proc /chroot_tor/proc
>
>is required, increasing the kernel and local
>process attack-surface substantially.  Salved the
>pain with
>
>   echo "1" >/proc/sys/kernel/modules_disabled
>
>'tor' is running on a box dedicated to
>routing and has no need for loading modules
>after boot completes.
>
>-----
>
>Since it works well I'll probably look at
>compiling other components with AS in a couple
>of weeks.  Those would primarily be
>
>   openssl
>   libevent
>   zlib
>
>Though a ball-of-yarn dimension exists in that
>one should probably also look into compiling
>
>   glibc
>
>with AS as well--a nightmare I suspect.
>
>Hopefully applying AS to the 'tor' daemon
>has enhanced trip-wiring of much of the
>available the attack surface.  Looking
>forward to running with the upcoming
>'seccomp' sandbox.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tor-0.2.4.18-rc-as.patch
Type: application/octet-stream
Size: 2132 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140408/2988133f/attachment.obj>