View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003004 | unreal | ircd | public | 2006-07-22 09:21 | 2006-11-11 14:30 |
| Reporter | Assigned To | syzop | |||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | All | OS Version | HPUX (..) | ||
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.2.6 | ||||
| Summary | 0003004: 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) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
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) |
|
|
I believe MAXTARGETS should be applied here, too. |
|
|
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. |
|
|
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 ;). |
|
|
Fixed in 32* (.588) and 33* (.2294) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-22 09:21 |
|
New Issue | |
| 2006-07-22 09:22 |
|
Relationship added | child of 0002936 |
| 2006-07-22 09:56 |
|
Note Added: 0012079 | |
| 2006-07-22 09:57 |
|
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 |
