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.