Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[teor]

> On 12 Dec. 2016, at 09:46, niftybunny  wrote:
> 
> Playing devils advocate here.
> 
> People want the T-Shirts. Its free advertisement for Tor. Perhaps it would be 
> great if people could get T-Shirts in
> exchange for other goods. Like this:
> 
> http://i.imgur.com/9Y8p7.gif
> 
> A long time ago this was possible: 
> https://www.torservers.net/wiki/tshirt/index#order
> 
> Perhaps we should do this again and #MAKETORGREATAGAIN
> 
> Markus

It is possible to donate and get a t-shirt:

https://donate.torproject.org/

We learnt a lot from doing it last year, and we have plans to make it
more efficient this year. (And get more people on it.)

We have already gone from having 0 paid people on it, to having 1
paid person on it (and they do many other tasks as well). I think we
are getting more to help over the next few months.

This should hopefully help relay operators get t-shirts as well.

Get back to us in early March if it hasn't worked out by then, and I'll
make sure I follow it up at the next Tor Meeting.

Tim

>> On 11 Dec 2016, at 22:50, Moritz Bartl  wrote:
>> On 12/10/2016 09:52 PM, pa011 wrote:
 btw, it would be awesome to give away t-shirts or something for running
 diverse relays.
>>> that was a least a promise the year ago (its not any more)
>>> - and I believe one should stand to his promises
>> 
>> I don't know where this idea is coming from that it's not any more the
>> case. I have not heard of any changes in that respect, the instructions
>> are still the same: https://www.torproject.org/getinvolved/tshirt.html
>> 
>> You need to email tshirts@, include your fingerprints, and then wait
>> weeks or months until the one poor person that is processing all the
>> requests and all the requests from the campaign and also has other hats
>> to get to it.
>> 
>> It's a thank you gift. I don't mean you, pa011, when I say this, but in
>> general I would expect a bit more gratitude and understanding what it
>> means to run a small understaffed organization. :(
>> 
>> Moritz
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[niftybunny]

Playing devils advocate here.

People want the T-Shirts. Its free advertisement for Tor. Perhaps it would be 
great if people could get T-Shirts in
exchange for other goods. Like this:

http://i.imgur.com/9Y8p7.gif 

A long time ago this was possible: 
https://www.torservers.net/wiki/tshirt/index#order 


Perhaps we should do this again and #MAKETORGREATAGAIN

Markus


> On 11 Dec 2016, at 22:50, Moritz Bartl  wrote:
> On 12/10/2016 09:52 PM, pa011 wrote:
>>> btw, it would be awesome to give away t-shirts or something for running
>>> diverse relays.
>> that was a least a promise the year ago (its not any more)
>> - and I believe one should stand to his promises
> 
> I don't know where this idea is coming from that it's not any more the
> case. I have not heard of any changes in that respect, the instructions
> are still the same: https://www.torproject.org/getinvolved/tshirt.html
> 
> You need to email tshirts@, include your fingerprints, and then wait
> weeks or months until the one poor person that is processing all the
> requests and all the requests from the campaign and also has other hats
> to get to it.
> 
> It's a thank you gift. I don't mean you, pa011, when I say this, but in
> general I would expect a bit more gratitude and understanding what it
> means to run a small understaffed organization. :(
> 
> Moritz
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Moritz Bartl]

On 12/10/2016 09:52 PM, pa011 wrote:
>> btw, it would be awesome to give away t-shirts or something for running
>> diverse relays.
> that was a least a promise the year ago (its not any more)
> - and I believe one should stand to his promises

I don't know where this idea is coming from that it's not any more the
case. I have not heard of any changes in that respect, the instructions
are still the same: https://www.torproject.org/getinvolved/tshirt.html

You need to email tshirts@, include your fingerprints, and then wait
weeks or months until the one poor person that is processing all the
requests and all the requests from the campaign and also has other hats
to get to it.

It's a thank you gift. I don't mean you, pa011, when I say this, but in
general I would expect a bit more gratitude and understanding what it
means to run a small understaffed organization. :(

Moritz
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

pa011:
> Could you give some explanation please on the difference between:

> -lots of challenge ACKs
received exactly the same number of chacks as number of sent RSTs (fixed
kernel, sysctl workaround, ...)
> -one challenge ACK
received just one chack during this connection
> -two challenge ACKs
received one chack after first RST burst, another one after second burst
> -vulnerable
100chacks/s rate limit was hit twice
> -zero challenge
RFC5961 is not supported
> -multiple challenge ACKs
anything else, i.e. there are some random number of chacks received but
less than number of sent RSTs, probably rate-limited

Current (these) definitions are here [1]. But they are a subject of
change, because I'm trying to improve scanning method (separating
counters for each of bursts).

[1] https://github.com/nogoegst/grill/blob/master/verdict/verdict.go
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[pa011]

Am 10.12.2016 um 21:12 schrieb Ivan Markin:
> pa011:
>> What about relays not on the list at all?
> 
> You mean that are not subscribed for tor-relays@?

No, forget that one - was my mistakable in the spreadsheet 
> 
> btw, it would be awesome to give away t-shirts or something for running
> diverse relays.

that was a least a promise the year ago (its not any more)- and I believe one 
should stand to his promises
> 
>> I would assume that not everybody of that 23 percent does know what
>> exactly to do, apart from better running on BSD - could you please
>> give detailed recommendation for beginners - your discussion seems on
>> a high level :-)
> 
> Agree, I personally don't see any way to notify these operators about
> what to do (except clear instructions at blog.tpo or tor-relays@).
> With pleasure. 

Yes please spread this out - as simple as possible - the list has about 1700 
hundret subscribers I, if I am correct - I reckon the  important and interested 
ones are on it 

There is an awesome The Tor BSD Diversity Project. The
> instructions for BSD beginners can be found here [1].

I used them about a week ago - they were the best I could find - sure they have 
room for improvement, especially for beginners, but there are several nice 
people out there -glad to help - some awful question have me done here by me 
already

> [1] https://torbsd.github.io/relay-guides.html

Could you give some explanation please on the difference between:

-lots of challenge ACKs
-multiple challenge ACKs
-one challenge ACK
-two challenge ACKs
-vulnerable
-zero challenge

Thanks 
Paul


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

pa011:
> What about relays not on the list at all?

You mean that are not subscribed for tor-relays@?

btw, it would be awesome to give away t-shirts or something for running
diverse relays.

> I would assume that not everybody of that 23 percent does know what
> exactly to do, apart from better running on BSD - could you please
> give detailed recommendation for beginners - your discussion seems on
> a high level :-)

Agree, I personally don't see any way to notify these operators about
what to do (except clear instructions at blog.tpo or tor-relays@).
With pleasure. There is an awesome The Tor BSD Diversity Project. The
instructions for BSD beginners can be found here [1].

[1] https://torbsd.github.io/relay-guides.html
--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[pa011]

> I would however be very interested to hear back from tor-relay operators
> if any of them have found Challenge ACK counter values higher than
> a million... which would indicate some kind of funny business.
> 
Thanky you for your work.

I know of 3 relays with ACK above 1 million:

TCPChallengeACK: 1081146
TCPSYNChallenge: 1062995

TCPChallengeACK: 1270948
TCPSYNChallenge: 1254428
  
TCPChallengeACK: 1189549
TCPSYNChallenge: 1171422

all running under Linux vm20198 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 
(2016-10-19) x86_64 GNU/Linux

There seems to be no relation between uptime of the server and challenges apart 
from rebooting, which resets to 0.

What about relays not on the list at all?

I would assume that not everybody of that 23 percent does know what exactly to 
do, apart from better running on BSD - could you please give detailed 
recommendation for beginners - your discussion seems on a high level :-)

Thanks and regards 

Paul
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

dawuud:
>>> Maybe you could also implement my Tor guard discovery
>>> attack that uses this vulnerability?
>>
>> Why not. I just don't know what the attack is. Can you point me to it?
> 
> On second thought I guess we better stick to writing scanners because if we
> start writing exploits then eventually some script kitty will come along and
> try to attack the Tor network with it; and even though my attack might not 
> work
> it involves doing various things that utilize resources on the Tor network;
> so it would be bad for the health of the Tor network.

Right, I didn't mean that to be an exploit but just a PoC of this attack
vector. But you're right, I haven't thought that it will put load on the
network, and doing this is definitely not OK. It's not just some
harmless TCP segments, there is much more than this (circuit rebuilding,
etc).

> It's traffic profile would be obviously identifiable for passive network 
> observers.
> A nation state actor would have much better/faster results using other
> well known publicly documented Tor guard discovery attacks.
> Pretty sure they like to be sneaky when they deanonymize Tor circuits.

I doesn't mean that nobody would like to use it. There are attackers
that use botnets to do their nasty business and they don't care much
about how visible it is.

> I would however be very interested to hear back from tor-relay operators
> if any of them have found Challenge ACK counter values higher than
> a million... which would indicate some kind of funny business.

It may not indicate this. Since I was able to scan whole Tor network in
just 7 minutes (someone can use more than 127 concurrent scans and scan
even faster), it may indicate that there is some aggressive scanning is
going on by multiple parties.

--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[dawuud]

> > btw i'm surprised you wrote 
> > https://github.com/nogoegst/rough/blob/master/tcp.go
> > instead of using https://github.com/google/gopacket
> 
> You shouldn't; rough is just a convenient wrapper on top of TCP-ish
> stuff from gopacket (it makes TCP hacks simpler).

ah right. cool.

> > Maybe you could also implement my Tor guard discovery
> > attack that uses this vulnerability?
> 
> Why not. I just don't know what the attack is. Can you point me to it?

On second thought I guess we better stick to writing scanners because if we
start writing exploits then eventually some script kitty will come along and
try to attack the Tor network with it; and even though my attack might not work
it involves doing various things that utilize resources on the Tor network;
so it would be bad for the health of the Tor network.

> > I've been asked to write a proof of concept but I don't feel motivated to 
> > do so.
> > Also, there are some doubts about weather this guard discovery attack would 
> > be
> > feasible on the real Tor network... though we could probably make it work 
> > in a test network.
> > 
> > Now that such a small percentage of the Tor network is vulnerable it's 
> > probably safe/responsible
> > for me to post my theoretic Tor guard discovery attack, right?
> 
> Hmm, I *don't* think that 1/4 of the network is actually small
> percentage... [I think we should somehow encourage vulnerable relays to
> update their kernels to lower affected percentage below ~10-15%.]

> Also, you saying "guard discovery attack based on pure off-path TCP
> attack" make this *slightly* obvious. So if someone actually got it,
> it's likely that they're already exploiting it.

It's traffic profile would be obviously identifiable for passive network 
observers.
A nation state actor would have much better/faster results using other
well known publicly documented Tor guard discovery attacks.
Pretty sure they like to be sneaky when they deanonymize Tor circuits.

I would however be very interested to hear back from tor-relay operators
if any of them have found Challenge ACK counter values higher than
a million... which would indicate some kind of funny business.


Cheers,
David


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

dawuud:
> The Golang rewrite of the scanner is cool!

Thanks!

> btw i'm surprised you wrote 
> https://github.com/nogoegst/rough/blob/master/tcp.go
> instead of using https://github.com/google/gopacket

You shouldn't; rough is just a convenient wrapper on top of TCP-ish
stuff from gopacket (it makes TCP hacks simpler).

> Maybe you could also implement my Tor guard discovery
> attack that uses this vulnerability?

Why not. I just don't know what the attack is. Can you point me to it?

> I've been asked to write a proof of concept but I don't feel motivated to do 
> so.
> Also, there are some doubts about weather this guard discovery attack would be
> feasible on the real Tor network... though we could probably make it work in 
> a test network.
> 
> Now that such a small percentage of the Tor network is vulnerable it's 
> probably safe/responsible
> for me to post my theoretic Tor guard discovery attack, right?

Hmm, I *don't* think that 1/4 of the network is actually small
percentage... [I think we should somehow encourage vulnerable relays to
update their kernels to lower affected percentage below ~10-15%.]
Also, you saying "guard discovery attack based on pure off-path TCP
attack" make this *slightly* obvious. So if someone actually got it,
it's likely that they're already exploiting it.

--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[dawuud]

Hi Ivan and tor-relay operators,


The Golang rewrite of the scanner is cool!

btw i'm surprised you wrote https://github.com/nogoegst/rough/blob/master/tcp.go
instead of using https://github.com/google/gopacket

Maybe you could also implement my Tor guard discovery
attack that uses this vulnerability?

I've been asked to write a proof of concept but I don't feel motivated to do so.
Also, there are some doubts about weather this guard discovery attack would be
feasible on the real Tor network... though we could probably make it work in a 
test network.

Now that such a small percentage of the Tor network is vulnerable it's probably 
safe/responsible
for me to post my theoretic Tor guard discovery attack, right?


Sincerely,

David

On Fri, Dec 09, 2016 at 05:31:00AM +, Ivan Markin wrote:
> Hi tor-relays@,
> 
> Getting back with more results on this.
> I've implemented CVE-2016-5696 scanner in Go [1] and scanned the Tor
> network several times [2].
> First results I've got using technique similar to David's (sending 500
> RSTs in one burst), second ones are got via another method (send 111
> RSTs in burst and then 111 RSTs 1 second later*).
> 
> Current statistics:
> 32% of Linux relays are vulnerable. That is 23% of Tor network.
> 
> --
> 
> Now some magic! Those 3 NetBSD relays from before still behave like they
> are vulnerable Linuxes (as they did in David's scanner, and two of mine):
> 
> $ cat grill-tor-2016-12-09 | grep -v Linux | grep vulnerable
> 78.47.45.36:9001,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,Tor 0.2.8.9 on
> NetBSD,200,1.847787ms,1.834238ms,vulnerable
> 86.62.117.171:63500,508004552343E5374B6570C76E9239AA23310684,Tor
> 0.2.5.10 on NetBSD,200,1.999138ms,1.839057ms,vulnerable
> 139.18.25.35:9001,8806C3E6FA42B07113F3A1553DE70C0A30101201,Tor 0.2.8.9
> on NetBSD,200,3.936046ms,3.777501ms,vulnerable
> 
> Yes, nmap -O reports them to be NetBSD hosts.
> 
> Actually I don't know what's going on here. Thoughts:
>  * relays are behind vulnerable Linux middleboxes
>  * RFC 5961 got implemented partly in NetBSD and it is actually vulnerable
>  * ???
> 
> Okay then. I've brought up NetBSD 7.0.2 VM and scanned it locally. 0
> challenge ACKs. Fine. I've put it under vulnerable Linux DNAT and it was
> 'kinda' vulnerable (some small random amount of ChACKs). Probably I did
> something wrong here.
> I headed out and scanned netbsd.org (self-hosted?) and it's vulnerable also.
> 
> I've lurked through NetBSD's src code and found some bits of RFC5961.
> But I was unable to see anything offensive.
> 
> If someone have some insight on this dark magic, that would be awesome!
> 
> ---
> 
> Thanks for bringing up the diversity issue in light of this CVE, Alex!
> Just to make everyone feel sad today:
> 
> $ cat grill-tor-2016-12-09 | grep -v offline | grep Linux | wc -l
> 6435
> $ cat grill-tor-2016-12-09 | grep -v offline | grep -v Linux | wc -l
>  550
> 
> Sadly, Linuxes are typical ~2σ of the network. ;(
> Please run more different (e.g. BSD) relays!
> 
> [*] I think it should be more accurate.
> [1] https://github.com/nogoegst/grill
> [2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de
> 
> --
> Happy life without suffering,
> Ivan Markin
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


signature.asc
Description: PGP signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

teor:
> For Tor client path selection, it is typically the vulnerable consensus
> weight that matters, not the number of relays.
> (Except in the case of HSDirs, where the hash ring is unweighted.)
> 
> Have you looked at the vulnerable consensus weight proportion?

Thanks for the tip! Laziness just took over me then.

It turns out that vulnerable consensus weight fraction is 0.249602 or 25%.

--
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[niftybunny]

4 server rebooted, thank you very much.

markus



> On 9 Dec 2016, at 06:31, Ivan Markin  wrote:
> 
> Hi tor-relays@,
> 
> Getting back with more results on this.
> I've implemented CVE-2016-5696 scanner in Go [1] and scanned the Tor
> network several times [2].
> First results I've got using technique similar to David's (sending 500
> RSTs in one burst), second ones are got via another method (send 111
> RSTs in burst and then 111 RSTs 1 second later*).
> 
> Current statistics:
> 32% of Linux relays are vulnerable. That is 23% of Tor network.
> 
> --
> 
> Now some magic! Those 3 NetBSD relays from before still behave like they
> are vulnerable Linuxes (as they did in David's scanner, and two of mine):
> 
> $ cat grill-tor-2016-12-09 | grep -v Linux | grep vulnerable
> 78.47.45.36:9001,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,Tor 0.2.8.9 on
> NetBSD,200,1.847787ms,1.834238ms,vulnerable
> 86.62.117.171:63500,508004552343E5374B6570C76E9239AA23310684,Tor
> 0.2.5.10 on NetBSD,200,1.999138ms,1.839057ms,vulnerable
> 139.18.25.35:9001,8806C3E6FA42B07113F3A1553DE70C0A30101201,Tor 0.2.8.9
> on NetBSD,200,3.936046ms,3.777501ms,vulnerable
> 
> Yes, nmap -O reports them to be NetBSD hosts.
> 
> Actually I don't know what's going on here. Thoughts:
> * relays are behind vulnerable Linux middleboxes
> * RFC 5961 got implemented partly in NetBSD and it is actually vulnerable
> * ???
> 
> Okay then. I've brought up NetBSD 7.0.2 VM and scanned it locally. 0
> challenge ACKs. Fine. I've put it under vulnerable Linux DNAT and it was
> 'kinda' vulnerable (some small random amount of ChACKs). Probably I did
> something wrong here.
> I headed out and scanned netbsd.org (self-hosted?) and it's vulnerable also.
> 
> I've lurked through NetBSD's src code and found some bits of RFC5961.
> But I was unable to see anything offensive.
> 
> If someone have some insight on this dark magic, that would be awesome!
> 
> ---
> 
> Thanks for bringing up the diversity issue in light of this CVE, Alex!
> Just to make everyone feel sad today:
> 
> $ cat grill-tor-2016-12-09 | grep -v offline | grep Linux | wc -l
>6435
> $ cat grill-tor-2016-12-09 | grep -v offline | grep -v Linux | wc -l
> 550
> 
> Sadly, Linuxes are typical ~2σ of the network. ;(
> Please run more different (e.g. BSD) relays!
> 
> [*] I think it should be more accurate.
> [1] https://github.com/nogoegst/grill
> [2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de
> 
> --
> Happy life without suffering,
> Ivan Markin
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[teor]

> On 9 Dec. 2016, at 16:31, Ivan Markin  wrote:
> 
> Hi tor-relays@,
> 
> Getting back with more results on this.
> I've implemented CVE-2016-5696 scanner in Go [1] and scanned the Tor
> network several times [2].
> First results I've got using technique similar to David's (sending 500
> RSTs in one burst), second ones are got via another method (send 111
> RSTs in burst and then 111 RSTs 1 second later*).
> 
> Current statistics:
> 32% of Linux relays are vulnerable. That is 23% of Tor network.
> 
> --
> 
> Now some magic! Those 3 NetBSD relays from before still behave like they
> are vulnerable Linuxes (as they did in David's scanner, and two of mine):
> 
> $ cat grill-tor-2016-12-09 | grep -v Linux | grep vulnerable
> 78.47.45.36:9001,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,Tor 0.2.8.9 on
> NetBSD,200,1.847787ms,1.834238ms,vulnerable
> 86.62.117.171:63500,508004552343E5374B6570C76E9239AA23310684,Tor
> 0.2.5.10 on NetBSD,200,1.999138ms,1.839057ms,vulnerable
> 139.18.25.35:9001,8806C3E6FA42B07113F3A1553DE70C0A30101201,Tor 0.2.8.9
> on NetBSD,200,3.936046ms,3.777501ms,vulnerable
> 
> Yes, nmap -O reports them to be NetBSD hosts.
> 
> Actually I don't know what's going on here. Thoughts:
> * relays are behind vulnerable Linux middleboxes
> * RFC 5961 got implemented partly in NetBSD and it is actually vulnerable
> * ???
> 
> Okay then. I've brought up NetBSD 7.0.2 VM and scanned it locally. 0
> challenge ACKs. Fine. I've put it under vulnerable Linux DNAT and it was
> 'kinda' vulnerable (some small random amount of ChACKs). Probably I did
> something wrong here.
> I headed out and scanned netbsd.org (self-hosted?) and it's vulnerable also.
> 
> I've lurked through NetBSD's src code and found some bits of RFC5961.
> But I was unable to see anything offensive.
> 
> If someone have some insight on this dark magic, that would be awesome!
> 
> ---
> 
> Thanks for bringing up the diversity issue in light of this CVE, Alex!
> Just to make everyone feel sad today:
> 
> $ cat grill-tor-2016-12-09 | grep -v offline | grep Linux | wc -l
>6435
> $ cat grill-tor-2016-12-09 | grep -v offline | grep -v Linux | wc -l
> 550
> 
> Sadly, Linuxes are typical ~2σ of the network. ;(
> Please run more different (e.g. BSD) relays!
> 
> [*] I think it should be more accurate.
> [1] https://github.com/nogoegst/grill
> [2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de

Hi Ivan,

Thanks for doing this work, and the reminder to upgrade (or install a
non-Linux OS).

For Tor client path selection, it is typically the vulnerable consensus
weight that matters, not the number of relays.
(Except in the case of HSDirs, where the hash ring is unweighted.)

Have you looked at the vulnerable consensus weight proportion?

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Network scan results for CVE-2016-5696 / RFC5961

[Ivan Markin]

Hi tor-relays@,

Getting back with more results on this.
I've implemented CVE-2016-5696 scanner in Go [1] and scanned the Tor
network several times [2].
First results I've got using technique similar to David's (sending 500
RSTs in one burst), second ones are got via another method (send 111
RSTs in burst and then 111 RSTs 1 second later*).

Current statistics:
32% of Linux relays are vulnerable. That is 23% of Tor network.

--

Now some magic! Those 3 NetBSD relays from before still behave like they
are vulnerable Linuxes (as they did in David's scanner, and two of mine):

$ cat grill-tor-2016-12-09 | grep -v Linux | grep vulnerable
78.47.45.36:9001,3F5440FF003DFF8A12AA308CFD4087FBC157ABE0,Tor 0.2.8.9 on
NetBSD,200,1.847787ms,1.834238ms,vulnerable
86.62.117.171:63500,508004552343E5374B6570C76E9239AA23310684,Tor
0.2.5.10 on NetBSD,200,1.999138ms,1.839057ms,vulnerable
139.18.25.35:9001,8806C3E6FA42B07113F3A1553DE70C0A30101201,Tor 0.2.8.9
on NetBSD,200,3.936046ms,3.777501ms,vulnerable

Yes, nmap -O reports them to be NetBSD hosts.

Actually I don't know what's going on here. Thoughts:
 * relays are behind vulnerable Linux middleboxes
 * RFC 5961 got implemented partly in NetBSD and it is actually vulnerable
 * ???

Okay then. I've brought up NetBSD 7.0.2 VM and scanned it locally. 0
challenge ACKs. Fine. I've put it under vulnerable Linux DNAT and it was
'kinda' vulnerable (some small random amount of ChACKs). Probably I did
something wrong here.
I headed out and scanned netbsd.org (self-hosted?) and it's vulnerable also.

I've lurked through NetBSD's src code and found some bits of RFC5961.
But I was unable to see anything offensive.

If someone have some insight on this dark magic, that would be awesome!

---

Thanks for bringing up the diversity issue in light of this CVE, Alex!
Just to make everyone feel sad today:

$ cat grill-tor-2016-12-09 | grep -v offline | grep Linux | wc -l
6435
$ cat grill-tor-2016-12-09 | grep -v offline | grep -v Linux | wc -l
 550

Sadly, Linuxes are typical ~2σ of the network. ;(
Please run more different (e.g. BSD) relays!

[*] I think it should be more accurate.
[1] https://github.com/nogoegst/grill
[2] https://gist.github.com/nogoegst/d2de330b794b47158b4cfbed0987b4de

--
Happy life without suffering,
Ivan Markin
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays