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.