Re: [tor-relays] running Tor relay live with AddressSanitizer

[starlight.2014q2@xxxxxxxxxxx]

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.2014q2@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays