[tor-bugs] #16052 [Tor]: Hidden service socket exhaustion by opening many connections

[Tor Bug Tracker & Wiki]

#16052: Hidden service socket exhaustion by opening many connections
------------------------+------------------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-hs dos SponsorR SponsorU
Actual Points:          |  Parent ID:
       Points:          |
------------------------+------------------------------------------

Comment (by yawning):

 Replying to [comment:14 asn]:
 > Then, I did a bit of testing with Yawning's branch. With the naive
 attack, it seems that Yawning's branch works as intended (ignores
 superfluous `RELAY_BEGIN` cells) but it doesn't stop the DoS. That is, the
 whole system still goes at 100% CPU just because of cell processing (I
 think).

 Well, it stops the DoS in that, despite the load being at 100%, new
 connections (and existing ones) will continue to get serviced (if they
 weren't it would be a sign that our circuit level scheduling is broken,
 which it isn't).

 If the goal here is to keep CPU load down when bad guys can send arbitrary
 traffic down one circuit, then a trivial way for the bad guys to drive
 load up to 100% would be to spam `DROP` cells.  There's ever so slightly
 less processing involved for `DROP` cells than ignored `BEGIN` cells, but
 not enough that that variant of the attack isn't possible to mount.

 > If we change Yawning's patch to tear down the circuit after the max
 number of streams have been encountered, then it seems to work better.
 >
 > We discussed making this behavior more configurable by having two
 switches:
 >
 > `HiddenServiceMaxStreams`: The maximum number of simultaneous streams on
 an HS circuit.
 >
 > `HiddenServiceMaxStreamsCloseCircuit`: If set, then when
 `HiddenServiceMaxStreams` is triggered, we close the respective circuit.
 If not set, we just ignore requests for superfluous streams. (Default:
 off)
 >
 > (The positive thing of not killing the circuit above, is that the
 circuit will recover once the number of streams goes below the threshold)

 Some people on IRC seem to think that once a circuit trips the threshold
 we should stop sending SENDME cells.  I don't particularly think that the
 behavior with my branch is broken though, and I'm still refactoring the
 linked list code so I'll think about that later.

 Note to the peanut gallery: There is still NO guarantee that I got the
 stream accounting I added correct, and using my branch is still not
 advised.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16052#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online