Greetings Tor relay operators,
First of all, if you operate non-Linux Tor relays then good job! Thanks! This notice isn't for you. Only Linux is affected.
This morning I scanned the tor network for vulnerability to CVE-2016-5696 [1], again so that I could compare the results with the scan from last month. Linux implemented RFC 5961 [2] using a global counter which can be used as a side channel allowing blind TCP injection and other consequences as well.
I used this collector consensus file for my scan: https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-1...
That's 7080 relays. The scan produced:
246 relays had connection timeouts and were not scanned. 60 relays had connection refused. 6795 relays scanned. 2034 relays are vulnerable according to the rationale I used a month ago to categorized the results as vulnerable (if the probe response receives between 90 and 220 Challenge ACKs).
These results should be reproducible. The source code to the scanner is here: https://github.com/david415/scan_tor_rfc5961
Last month's scan showed 4069 vulnerable relays. Each probe does a TCP handshake and then sends 500 in-window packets and counts the resulting Challenge ACKs. (followed by a TCP connection close). However we've updated the buckets of probe results to this:
"r == 0" : "zero challenge ACKs", "0 < r <= 10" : "probably new kernel", "10 < r <= 20" : "maybe new kernel?", "20 < r <= 90" : "inconclusive?", "90 < r < 100" : "probably vulnerable", "(r%100)==0 and 0<r<500" : "almost definitely vulnerable", "(r%100)!=0 and 100<r<450" : "probably vulnerable", "(r%100)!=0 and 450<=r<=490" : "inconclusive?", "490 < r < 500" : "most likely applied sysctl workaround", "r == 500" : "probably applied sysctl workaround", "500 < r" : "extra duplicate packets?",
The researchers who discovered this vulnerability published an excellent paper [3]. Although they incorrectly described an attack on tor's path selection it may be possible that other attacks on the Tor network are possible. I think it would be better to upgrade and reboot your relays rather than risk the Tor network's exposure to attacks that may utilize CVE-2016-5696 in combination with other techniques. Furthermore being vulnerable to CVE-2016-5696 also implies that you have a Linux kernel which is also vulnerable to dirty COW; https://dirtycow.ninja
If you operate a relay you can check to see if your relay's TCP stack has counted many TCP Challenge ACKs. Please let us know if your counters have very high values.
Vulnerable Linux kernels will have snmp stat counters like this::
root:/# netstat -s | grep -i challenge TCPChallengeACK: 113338 TCPSYNChallenge: 1157
High counter values maybe indicative of attacks. Linux 4.7.x has got a per socket rate limiting feature which if it has a high value may also be indicative of attack attempts and probing::
root:/# netstat -s | grep -i challenge TCPChallengeACK: 2614 TCPSYNChallenge: 442 TCPACKSkippedChallenge: 141795
If you are too lazy to upgrade your Linux kernel and reboot then you may apply a convenient workaround:
sysctl net.ipv4.tcp_challenge_ack_limit=9999999999
read more about this workaround here:
https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-stac...
Special thanks to Least Authority for supporting my research.
sincerely,
David Stainton
1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696
2. https://tools.ietf.org/html/rfc5961
3. Off-Path TCP Exploits: Global Rate Limit Considered Dangerous http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf