View Issue Details

IDProjectCategoryView StatusLast Update
0003004unrealircdpublic2006-11-11 14:30
ReporterstskeepsAssigned Tosyzop 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
PlatformOSAllOS VersionHPUX (..)
Product Version3.2.6 
Target VersionFixed in Version3.2.6 
Summary0003004: WebTV whois does not canonize nicknames as /whois does it.
Description/msg IRC whois yourself,yourself,yourself,yourself,yourself
can be abused to amplify proxy attacks quite a lot.

for (tmp = parv[1]; (nick = strtoken(&p, tmp, ",")); tmp = NULL)
in w_whois in webtv.c should read

for (tmp = canonize(parv[1]); (nick = strtoken(&p, tmp, ",")); tmp = NULL)


TagsNo tags attached.
3rd party modules

Relationships

child of 0002936 resolvedsyzop 3.2.6 Release 

Activities

stskeeps

2006-07-22 09:56

reporter   ~0012079

Anything that uses ,'s stuff, should canonize and add penalty. Observe /whois a,b,c,d,e,f,g,h,i,k,l,m,n,o,p (..till 512 bytes)

satmd

2006-07-22 10:00

reporter   ~0012080

I believe MAXTARGETS should be applied here, too.

satmd

2006-07-22 10:15

reporter   ~0012081

I've just played with it
I completely erased w_whois from my sources dir.

Now I get native WHOIS replies for /msg IRC whois a,b,c,d,a,b,c,d ... canonicalized.

Wouldn't this be the proper solution: parse the replies for WebTV users and replace them by PRIVMSG?

This way, we would a) have less code reduncance (penalty stuff), b) don't need to canonicalize, c) would "translate" replies in the right place.

syzop

2006-08-03 17:12

administrator   ~0012134

Well, canonizing is not the solution, but maybe you used the wrong term. what canonize() does is simply take out duplicates, you can still flood if you have multiple targets (exactly like your a,b,c,d,.. example).
Now enforcing MAXTARGETS is a better idea.
And guess what? I already implemented that in /whois (in 3.2.5), even though many (if not all) ircds don't enforce any such limit :P.
So are we better? No they actually got a point as well... Namely that you can cause huuuge amounts of traffic as well if you do, for example, 'who #bigchan' (now that's a short command, and returns a lot of data)... so is blocking all those other commands still very useful? Not to mention that exactly for this kind of flooding there's max sendq.
My decision was, sure we'll implement it here and there, like whois (so will fix webtv's whois as well), but just keep in mind that it's of relatively little use on a reasonably sized network (though, not zero use).

IRC MATH LESSON:
Assume 200 targets in one whois (this is too much, but we'll take it anyway)... whois I had on avg was 408 per target, 408 * 200 = 81K
Assume a channel with 300 users, who output I had on avg was 127 per member, 127*300 = 38K
Thing is, the who thing you get with a simple 'WHO #somechannel' gives a penalty of 1 second. While your WHOIS thing (though twice as much output) eats your full penalty of 6 seconds.
So in practice, you can do 6 WHO requests which is 6*38K=228K, which is more than the one whois thing you could do in that time of 81K.
As you could calculate, WHO is better as a flood method with channels slightly bigger than 100 members (ofcourse, things vary per network and situation).
END OF MATH LESSON

Sometimes I wonder why others are not doing the same calculations, it's so obvious to me at least.. Perhaps I just have en evil mind! ;p


As for your webtv stuff satmd...
That sounds quite cpu intensive and ugly. Actually, I'm not considering improving webtv anymore, webtv's are being replaced by msntv2's these days anyway.. so they are dieing. No, I'm not considering ripping it out either, not at all... we'll be nice ;).

syzop

2006-11-11 14:30

administrator   ~0012623

Last edited: 2006-11-11 14:30

Fixed in 32* (.588) and 33* (.2294)

Issue History

Date Modified Username Field Change
2006-07-22 09:21 stskeeps New Issue
2006-07-22 09:22 stskeeps Relationship added child of 0002936
2006-07-22 09:56 stskeeps Note Added: 0012079
2006-07-22 09:57 stskeeps View Status private => public
2006-07-22 10:00 satmd Note Added: 0012080
2006-07-22 10:15 satmd Note Added: 0012081
2006-08-03 17:12 syzop Note Added: 0012134
2006-11-11 14:30 syzop Status new => resolved
2006-11-11 14:30 syzop Fixed in Version => 3.2.6
2006-11-11 14:30 syzop Resolution open => fixed
2006-11-11 14:30 syzop Assigned To => syzop
2006-11-11 14:30 syzop Note Added: 0012623
2006-11-11 14:30 syzop Note Edited: 0012623