Opened 4 years ago

Closed 3 years ago

#1527 closed defect (no response)

Mitigate amplification attacks via SSU

Reported by: str4d Owned by: zzz
Priority: minor Milestone: undecided
Component: router/transport Version: 0.9.19
Keywords: ssu Cc:
Parent Tickets: Sensitive: no

Description

Reported by Yawning in #tor-dev:

<Yawning> *looks at the ssu source for lols*
<Yawning> was wondering if it changed recently
<Yawning> wondering if I can turn i2p into a gigantic botnet still
<str4d> Leveraging the SSU transport? That would be the first I've heard of such a vector.
<Yawning> y'all should rate limit SessionCreated
<Yawning> I told someone about this :/
<Yawning> my understanding of the code may be too shallow
* str4d isn't the dev that works on SSU tho, so probably missed it
<Yawning> basically, send a ton of valid session created messages with a spoofed source ip
<Yawning> and abuse the fact that the signature gives you amplification of the response size
<Yawning> though y'all now support ecc so it's not as good as it used to be
<Yawning> if you want to fix it there's a few ways to
<Yawning> using a 4 way handshake would be what I would do if I were the one fixing it
<str4d> Hmm, I can't find any ticket mentioning it. Do you know who it was you told?
<Yawning> no, was a while ago
<str4d> Then I'm unsurprised it would fall through the cracks, tickets are really the only way we remember things :P
<Yawning> nb: my understanding of the code is not deep so it may infact be doing rate limiting
<Yawning> hidden in a tiny java routine somwhere
<str4d> Would not surprise me, we have limits all over the place
<Yawning> it'd be worth noting in the spec that implementations SHOULD implement mitigations for such things
<str4d> mmm
<str4d> There is an open ticket for implementing transport-layer replay prevention (https://trac.i2p2.de/ticket/1212), but this would be slightly different.
<Yawning> yeah, cus what I'd do is randomize the nonce each time
<Yawning> if I were designing something like SSU2, I'd probably knock off SCTP's 4 way handshake as well
<Yawning> INIT/INIT ACK/COOKIE/COOKIE ECHO
<Yawning> where cookie/cookie echo is the current 2 way handshake with an extra field
* goatandsheep has quit (Quit: Page closed)
<Yawning> basically, refusing to send the session created till the initiator proves it can receive traffic from the address it claims to be sitting on
<str4d> Yeah, that's what NTCP does
<Yawning> use something like HMAC-whatever over X | size | IP addr as the cookie or something
<Yawning> so the cookie sent back is tiny

Subtickets

Change History (3)

comment:1 Changed 4 years ago by zzz

I've made several passes through SSU in recent years (most of it in 2012) to bolster defenses for this type of stuff. Most of it is for the introducer and peer test mechanisms, which were pretty vulnerable. For the initial handshake (and I assume he means the first message in the handshake (Session Request) not the third message (Session Created)) - there are limits.

In EstablishmentManager?, concurrent inbound establishes are limited to a range of 10-75 based on configured bandwidth. See receiveSessionRequest(), shouldAllowInboundEstablishment(), etc.

Are these defenses adequate for the attack in the OP? Is there an attack for Session Created? For further research. Need some good minds looking at SSU for these issues. It takes a lot of work and brainstorming to harden a UDP protocol, and it wasn't rigorously reviewed or hardened back when it was created in 2005.

Note that we also reject requests apparently from low ports, which is an easy defense.

comment:2 Changed 4 years ago by zzz

Status: newinfoneeded_new

comment:3 Changed 3 years ago by zzz

Resolution: no response
Status: infoneeded_newclosed
Note: See TracTickets for help on using tickets.