[IRCServices] /ns ghost exploit

[Andrew Church]

     Well, I won't touch the security patch argument because I don't want
to bring years of Bugtraq debates into here, but as you say, we have
different points of view on this, so having a patch is probably the best
thing--it is open source, after all.

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>>      This is basically what I was trying to say.  In response to the
>> comment that GHOST could check the target's 
>> recognized/identified status
>> before killing, suppose the user hasn't identified when they get
>> disconnected (maybe their connection dropped just as they 
>> connected to IRC,
>> or maybe they didn't identify for some other reason)?
>
>In any scenario such as this, with a valid ghost where the ghost command no 
>longer functions, they could use the recover and release commands which 
>would allow them to use their nick again, the "ghost" would have it's nick 
>changed and would quit IRC naturally within a few minutes. A nick owner 
>does not lose the ability to use the nick just because ghost is made a 
>little more selective. The error message will be altered to direct a user 
>to use recover and release, thanks.
>
>The logic behind the use of nick status, is that it seems the simplest 
>method to determine the validity of a ghost. Checking other things such as 
>the connecting host/IP would have problems should the ghost occur because 
>of an ISP disconnect or redial. For static IPs it would be perfect. 
>Checking the access list against the ghost host, does not remove the 
>potential for abuse since an open access list would mean that the ghost 
>would always appear to be valid. So a decision was made to only assume that 
>fully identified nicknames are valid ghosts. 
>
>An alternative is to have a ghost system similar to guest nicks, but this 
>would provide no way to remove verifiable ghosts from IRC prior to their 
>natural timeout. This may not be a bad thing since it prevents unnecessary 
>killing but would obviously require much more patching of services to 
>implement and until services reaches a time when a branch is feasible, it 
>would not be something worth considering at this time. 
>
>>      The main point, though, is that if the person in question has
>> registered/linked those nicks, then from Services' point of 
>> view (and mine
>> as well) those nicks belong to that person, and they can do 
>> whatever they
>> want with them, including killing new users who try to use 
>> them.  
>
>AIUI GHOST was designed (and is described in the documentation) to remove 
>ghost sessions, not as a way for users to kill people using their 
>nicknames. 
>
>Using that logic, surely the recover command should ignore the 
>NSForceNickChange directive as well? Personally, we do not tend to give 
>users kill power on a server. Given the restrictions we have on it's use by 
>the administration of the network, it seems wrong to give a user the power 
>as part of the nickname ownership.
>
>Kill Immediate ON will protect a nickname from being used without ever 
>removing a person from a server and is in my opinion a far better system. 
>Kill quick will prevent a nickname being used for more than 20 seconds, and 
>normal kill for more than 60 seconds. All of these have minimal impact on 
>the user being "killed" since they merely have their nickname changed so 
>are able to read the message from services explaining why their nickname 
>was changed and even seek assistance if they still have problems. If killed 
>on sight, they do not get that opportunity and see no real reason for being 
>removed from the network. 
>
>>From a nick owner perspective, this protection exists whether or not the 
>nick owner is on IRC and without any effort on their part. A nick owner has 
>more than adequate protection of the name and ability to restrict it's use 
>without the need to kill users. 
>
>> As I said
>> before, if you have users abusing the command, deal with the users
>> individually; denying such people this one particular avenue 
>> of mischief
>> will just push them into another anyway.
>
>Personally I do not think that buttons with Do Not Press on them are a 
>particularly useful feature nor do I want the ongoing task of dealing with 
>this as each wave of newbies discover this trick. 
>
>I would prefer people to find other avenues of mischief, since this will 
>lead to a better overall package as each is addressed. Imagine if we avoid 
>applying OS security fixes assuming that if we do not fix them, at least 
>people will not look for new ones. The fact is, whether this is fixed or 
>not, people will continue to look for new avenues of mischief. The lag 
>services trick to "get around" mlock is one that was discovered by users 
>years ago or so and is one that still comes up regularly which shows that 
>discovering one exploit does not prevent the search for others. 
>
>I definitely do not want to put people off finding problems like this in 
>Services, since they are better found and fixed than waiting for a 
>particularly malicious user to utilise. 
>
>We obviously have vastly differing opinions on this matter. I have 
>suggested how I intend to close this loophole rather than "manage" it as 
>you suggested and the discussion on list has proved useful in spotting some 
>potential pitfalls which was my primary aim after you said you would not 
>consider fixing it. I am disappointed it will not be at least an option in 
>the main services package, but, since I already have to patch in odd things 
>anyway, it is just one more for the list.
>
>-- 
>Mark.
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices