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@binnacle.cx wrote:
At 18:14 10/24/2013 -0400, starlight.2013q4@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.