Opened 4 years ago
Closed 4 years ago
#1528 closed defect (duplicate)
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: |
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 (1)
comment:1 Changed 4 years ago by str4d
- Resolution set to duplicate
- Status changed from new to closed
Note: See
TracTickets for help on using
tickets.
Accidental duplicate of #1527 thanks to network churn.