Hi Jason,
Thanks for your observation. I'll try to investigate soon.
Cheers,
David
On Thu, Nov 17, 2016 at 12:02:05PM -0500, Jason Ross wrote:
> Hi David,
> Thanks for the heads up! It turns out that my relay is in the list of
> affected hosts, however, the kernel I was running
Hi all,
I'm sorry that there are some false positives.
I did previously test against a FreeBSD tor relay and presumed NetBSD
would have a similar result.
Thanks for looking closely at this Ivan.
It sounds like the scanner needs to be fixed.
I'll try to test with a netbsd host soon.
Cheers!
Hi David,
Thanks for your work!
dawuud:
> I added the scan output to the repo, this includes the output csv file
> and a list of vulnerable relays:
>
> https://github.com/david415/scan_tor_rfc5961/blob/master/scan_archive/nov17_2016/probe_out.csv
>
On a Raspberry pi... Linux 4.4.26+ #915 Thu Oct 20 17:02:14 BST 2016
armv6l GNU/Linux
$ netstat -s | grep -i challenge
TCPChallengeACK: 10
(no TCPSYNChallenge result ??)
Le 17/11/2016 à 20:24, Univibe a écrit :
> My relays have been patched to the latest available kernels, and
> aren't in
On a Debian 8 updated relay too :
# netstat -s | grep -i challenge
TCPChallengeACK: 19497
TCPSYNChallenge: 12991
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64
GNU/Linux
Something else for being sure ?
Le 17/11/2016 à 20:24, Univibe a écrit :
> $ ansible tor -a
My relays have been patched to the latest available kernels, and aren't in the
list of vulnerable relays, however they still show high values for
TCPSYNChallenge:
$ ansible tor -a 'bash -c "netstat -s | grep -i challenge"' -b --ask-become-pass
lon | SUCCESS | rc=0 >>
TCPChallengeACK:
Hi David,
Thanks for the heads up! It turns out that my relay is in the list of
affected hosts, however, the kernel I was running (3.16.36-1+deb8u1)
is claimed by Debian to be fixed (see:
https://security-tracker.debian.org/tracker/CVE-2016-5696).
Since your script determines whether the host is
