Opened 5 weeks ago

Last modified 10 days ago

#32794 needs_review defect

improve OOS (out-of-sockets) handler victim selection and more

Reported by: starlight Owned by:
Priority: Medium Milestone: Tor: 0.4.3.x-final
Component: Core Tor/Tor Version: Tor: 0.4.2.5
Severity: Normal Keywords: security 043-can
Cc: Actual Points:
Parent ID: Points:
Reviewer: nickm Sponsor:

Description

I find these revisions a benefit. Will create a branch on GitLab desired.

Child Tickets

Attachments (1)

tor-0.4.2.5-oos_select-git.patch (10.9 KB) - added by starlight 5 weeks ago.
patch vs master and 0.4.2.5

Download all attachments as: .zip

Change History (9)

Changed 5 weeks ago by starlight

patch vs master and 0.4.2.5

comment:1 Changed 5 weeks ago by nickm

Milestone: Tor: 0.4.3.x-final
Status: newneeds_review

comment:2 Changed 2 weeks ago by dgoulet

Reviewer: nickm

comment:3 Changed 2 weeks ago by nickm

Hi! I have some comments on the code, but before I get to them, we should talk about the approach.

The new algorithm seems to be

  1. Always keep OR-to-OR connections; always keep directory connections. Only inspect client-to-guard and exit connections.
  1. When discarding connections, discard those that were created most recently.

Is that right? If so, I wonder if there is some way that attacker can exploit this by making a bunch of directory connections, if our directory port is open. Maybe we should consider CONN_TYPE_DIR as well.

I also wonder if the attacker can reduce our number of available sockets by simply attempting a socket exhaustion attack. We'll kill off some of their connections, but we won't kill them all. If the attacker preserves the ones that we don't kill, they will always survive instead of any newer connections that we receive in the future. Can we do any better than this?

(Once we're in agreement here, we should describe the algorithm we want to follow in a patch to tor-spec.txt, so that the correct behavior is documented.)

comment:4 in reply to:  3 ; Changed 2 weeks ago by starlight

Replying to nickm:

Is that right? If so, I wonder if there is some way that attacker can exploit this by making a bunch of directory connections, if our directory port is open. Maybe we should consider CONN_TYPE_DIR as well.

Good point. I could rework it to sort OR-OR connections to a low priority band, the rest in a high band without excluding any category except listeners. Connection age sort within bands. Open to your thoughts on this.

I also wonder if the attacker can reduce our number of available sockets by simply attempting a socket exhaustion attack. We'll kill off some of their connections, but we won't kill them all. If the attacker preserves the ones that we don't kill, they will always survive instead of any newer connections that we receive in the future. Can we do any better than this?

Have further work where underlying circuits are killed rather than connections. Do you see that as improving this issue? And dynamic configuration of the limits for threshold min, max and soft nofiles.

(Once we're in agreement here, we should describe the algorithm we want to follow in a patch to tor-spec.txt, so that the correct behavior is documented.)

sure!

comment:5 in reply to:  4 Changed 2 weeks ago by starlight

Replying to starlight:

. . .could rework it to sort OR-OR connections to a low priority band. . .

Hmm. Then someone could create 100000 relays and DOS the network with connections to the good relays.

Perhaps weight the OR-OR connections by consensus weight? The new relays would all start at 20 with days available for mitigation.

comment:6 Changed 2 weeks ago by starlight

how about

two bands: [OR-OR] and [client-OR, exit, dir]; listeners exempt

but OR-OR connections with a weight lower than a configuration
(in consensus and locally) threshold, perhaps default 100
go in the not OR-OR band, i.e. new/trivial relays do not qualify

OR-OR band, lower kill priority
sorted connection age * weight with lower value higher kill priority

non OR-OR band, higher kill priority
sorted by connection age with newer at higher kill priority

?

Last edited 10 days ago by starlight (previous) (diff)

comment:7 Changed 11 days ago by nickm

I'm thinking that this sounds like it's getting closer to plausible, but I'd want to see pseudocode to be sure. I don't understand how killing circuits instead of connections would help with socket exhaustion, though.

I'm still wondering about the attack where the attacker reduces the number of available sockets. Not sure how bad that would actually be.

comment:8 Changed 11 days ago by nickm

Keywords: security 043-can added
Note: See TracTickets for help on using tickets.