Finally got around to compiling 'openssl' and 'libevent' with AddressSanitizer. Found and patched one minor bug as a consequence
https://trac.torproject.org/projects/tor/ticket/12227 After running for a week the relay lost its guard status due to declining BWAUTH measurements. At the time Comcast seemed to be having network problems so I'm not sure if the slowdown from ASan in 'openssl' or Comcast was the cause. Buffer stats showed 80% of cells getting queued and an average delay of 380 ms the day before the guard flags was axed. Much better on earlier days. One BWAUTH had the relay at 400 KBytes/sec so I'm inclined to think the problem was Comcast. Anyway, switched to running just 'libssl.so' with ASan and running the normal 'libcrypto.so' on the theory that the latter is CPU intensive and at least one call-level below the surface, while the former is the easier to exploit attackable-surface component. Couldn't find any CVE's mentioning 'libcrypto.so' as having an exploitable flaw --ever. Started with new keys and it's back to being a Guard and the buffer stats are much better than even the good days from running 'libcrypto.so' with ASan. At 23:53 4/10/2014 -0400, starlight.201...@binnacle.cx wrote: >I updated the patch to > >1) have AS close /proc > >2) enable core dump files > >One should add > > /proc /chroot_tor/proc none noauto,bind 0 0 > >to /etc/fstab (note the 'noauto'). >Then the 'tor' startup script does a > > mount /chroot_tor/proc > ...start tor > sleep 10 > umount /chroot_tor/proc > >And it works like a charm. 'tor' starts >up with full AddressSanitizer monitoring >but with no pesky /proc file system >available to potential attackers. > >Attached are the patch and the > /etc/rc.d/init.d/tor >startup script. > _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays