[IRCServices] /ns ghost exploit

[Mark Hetherington]

>      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.