View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002792 | unreal | ircd | public | 2006-02-04 11:17 | 2015-05-24 10:47 |
| Reporter | coekie | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | any | OS Version | any | ||
| Product Version | 3.2.4 | ||||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0002792: Desync: making an unkick/deopable kicker | ||||
| Description | This is a bug that is in many ircds (but the exact effects vary a bit) This may not be easy to fix. The problem is a kick coming from an "unexisting" client, which is discarded. If a kick and a kill or a nick collision of the kicker cross, the kick isn't propagated, leaving an unkickable/deopable (except on his own server or his side of the desync) op. This situation can only be fixed by an op on his server (if he hasn't kicked them already), or an oper killing him (and all his other desynced clients, happy hunting). Other servers won't accept modes from him anymore (they'll bounce), but they do accept his kicks. If he kicks everyone out, leaving him as the only one on the channel, servers will start to disagree on the timestamp, making his server bounce all modes from other clients on servers that join (without showing which client is causing that). So this makes an abuser look like he has some godly power, and can make it hard to get a taken over channel back into order. | ||||
| Steps To Reproduce | 2 servers: s1, s2 3 clients: c1, c1b on s1, c2 on s2 At roughly the same time the clients do: c1: /nick c c2: /nick c and /kick c1b Suppose c2(c) gets killed by the nick collision, then s1 won't accept the kick, leaving c1b opped on the channel, but unkick/deopable by anyone on s2. | ||||
| Additional Information | Same as for that other bug I reported: this bug is also in some other ircds, please don't make details public yet. Some people seem to think this bug is too hard to fix, because not accepting anything from "unexisting" clients is done before any parsing of the message. And well, you can't use it to do takeovers, so it's not critical. In my opinion it is a pretty bad bug when being abused, so it is worth being fixed, even if that's hard. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-02-04 11:17 | coekie | New Issue | |
| 2007-04-27 04:04 |
|
Status | new => acknowledged |
| 2007-07-18 07:28 |
|
Relationship added | child of 0003454 |
| 2008-02-11 15:35 | syzop | Relationship deleted | child of 0003454 |
| 2015-05-24 10:47 | syzop | Note Added: 0018335 | |
| 2015-05-24 10:47 | syzop | Status | acknowledged => resolved |
| 2015-05-24 10:47 | syzop | Resolution | open => fixed |
| 2015-05-24 10:47 | syzop | Fixed in Version | => 3.4-alpha1 |
| 2015-05-24 10:47 | syzop | View Status | private => public |
