[tor-relays] network scan results for CVE-2016-5696 / rfc 5961

[dawuud]

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-11-16-04-00-00-consensus

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-stack-implementation.html


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20161117/644cc3bd/attachment.sig>