1 <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 3.2//EN">
4 <TITLE> [IRCServices] /ns ghost exploit
6 <LINK REL=
"Index" HREF=
"index.html" >
7 <LINK REL=
"made" HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20/ns%20ghost%20exploit&In-Reply-To=">
8 <META NAME=
"robots" CONTENT=
"index,nofollow">
9 <META http-equiv=
"Content-Type" content=
"text/html; charset=us-ascii">
10 <LINK REL=
"Previous" HREF=
"002860.html">
11 <LINK REL=
"Next" HREF=
"002862.html">
13 <BODY BGCOLOR=
"#ffffff">
14 <H1>[IRCServices] /ns ghost exploit
</H1>
16 <A HREF=
"mailto:ircservices%40ircservices.za.net?Subject=%5BIRCServices%5D%20/ns%20ghost%20exploit&In-Reply-To="
17 TITLE=
"[IRCServices] /ns ghost exploit">achurch at achurch.org
19 <I>Fri Mar
15 16:
19:
00 PST
2002</I>
21 <LI>Previous message:
<A HREF=
"002860.html">[IRCServices] /ns ghost exploit
23 <LI>Next message:
<A HREF=
"002862.html">[IRCServices] Services Admins and Opers?
25 <LI> <B>Messages sorted by:
</B>
26 <a href=
"date.html#2861">[ date ]
</a>
27 <a href=
"thread.html#2861">[ thread ]
</a>
28 <a href=
"subject.html#2861">[ subject ]
</a>
29 <a href=
"author.html#2861">[ author ]
</a>
34 <PRE> Well, I won't touch the security patch argument because I don't want
35 to bring years of Bugtraq debates into here, but as you say, we have
36 different points of view on this, so having a patch is probably the best
37 thing--it is open source, after all.
40 <A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">achurch at achurch.org
</A>
41 <A HREF=
"http://achurch.org/">http://achurch.org/
</A>
43 >><i> This is basically what I was trying to say. In response to the
44 </I>>><i> comment that GHOST could check the target's
45 </I>>><i> recognized/identified status
46 </I>>><i> before killing, suppose the user hasn't identified when they get
47 </I>>><i> disconnected (maybe their connection dropped just as they
48 </I>>><i> connected to IRC,
49 </I>>><i> or maybe they didn't identify for some other reason)?
51 </I>><i>In any scenario such as this, with a valid ghost where the ghost command no
52 </I>><i>longer functions, they could use the recover and release commands which
53 </I>><i>would allow them to use their nick again, the
"ghost
" would have it's nick
54 </I>><i>changed and would quit IRC naturally within a few minutes. A nick owner
55 </I>><i>does not lose the ability to use the nick just because ghost is made a
56 </I>><i>little more selective. The error message will be altered to direct a user
57 </I>><i>to use recover and release, thanks.
59 </I>><i>The logic behind the use of nick status, is that it seems the simplest
60 </I>><i>method to determine the validity of a ghost. Checking other things such as
61 </I>><i>the connecting host/IP would have problems should the ghost occur because
62 </I>><i>of an ISP disconnect or redial. For static IPs it would be perfect.
63 </I>><i>Checking the access list against the ghost host, does not remove the
64 </I>><i>potential for abuse since an open access list would mean that the ghost
65 </I>><i>would always appear to be valid. So a decision was made to only assume that
66 </I>><i>fully identified nicknames are valid ghosts.
68 </I>><i>An alternative is to have a ghost system similar to guest nicks, but this
69 </I>><i>would provide no way to remove verifiable ghosts from IRC prior to their
70 </I>><i>natural timeout. This may not be a bad thing since it prevents unnecessary
71 </I>><i>killing but would obviously require much more patching of services to
72 </I>><i>implement and until services reaches a time when a branch is feasible, it
73 </I>><i>would not be something worth considering at this time.
75 </I>>><i> The main point, though, is that if the person in question has
76 </I>>><i> registered/linked those nicks, then from Services' point of
77 </I>>><i> view (and mine
78 </I>>><i> as well) those nicks belong to that person, and they can do
79 </I>>><i> whatever they
80 </I>>><i> want with them, including killing new users who try to use
83 </I>><i>AIUI GHOST was designed (and is described in the documentation) to remove
84 </I>><i>ghost sessions, not as a way for users to kill people using their
87 </I>><i>Using that logic, surely the recover command should ignore the
88 </I>><i>NSForceNickChange directive as well? Personally, we do not tend to give
89 </I>><i>users kill power on a server. Given the restrictions we have on it's use by
90 </I>><i>the administration of the network, it seems wrong to give a user the power
91 </I>><i>as part of the nickname ownership.
93 </I>><i>Kill Immediate ON will protect a nickname from being used without ever
94 </I>><i>removing a person from a server and is in my opinion a far better system.
95 </I>><i>Kill quick will prevent a nickname being used for more than
20 seconds, and
96 </I>><i>normal kill for more than
60 seconds. All of these have minimal impact on
97 </I>><i>the user being
"killed
" since they merely have their nickname changed so
98 </I>><i>are able to read the message from services explaining why their nickname
99 </I>><i>was changed and even seek assistance if they still have problems. If killed
100 </I>><i>on sight, they do not get that opportunity and see no real reason for being
101 </I>><i>removed from the network.
103 </I>>><i>From a nick owner perspective, this protection exists whether or not the
104 </I>><i>nick owner is on IRC and without any effort on their part. A nick owner has
105 </I>><i>more than adequate protection of the name and ability to restrict it's use
106 </I>><i>without the need to kill users.
108 </I>>><i> As I said
109 </I>>><i> before, if you have users abusing the command, deal with the users
110 </I>>><i> individually; denying such people this one particular avenue
111 </I>>><i> of mischief
112 </I>>><i> will just push them into another anyway.
114 </I>><i>Personally I do not think that buttons with Do Not Press on them are a
115 </I>><i>particularly useful feature nor do I want the ongoing task of dealing with
116 </I>><i>this as each wave of newbies discover this trick.
118 </I>><i>I would prefer people to find other avenues of mischief, since this will
119 </I>><i>lead to a better overall package as each is addressed. Imagine if we avoid
120 </I>><i>applying OS security fixes assuming that if we do not fix them, at least
121 </I>><i>people will not look for new ones. The fact is, whether this is fixed or
122 </I>><i>not, people will continue to look for new avenues of mischief. The lag
123 </I>><i>services trick to
"get around
" mlock is one that was discovered by users
124 </I>><i>years ago or so and is one that still comes up regularly which shows that
125 </I>><i>discovering one exploit does not prevent the search for others.
127 </I>><i>I definitely do not want to put people off finding problems like this in
128 </I>><i>Services, since they are better found and fixed than waiting for a
129 </I>><i>particularly malicious user to utilise.
131 </I>><i>We obviously have vastly differing opinions on this matter. I have
132 </I>><i>suggested how I intend to close this loophole rather than
"manage
" it as
133 </I>><i>you suggested and the discussion on list has proved useful in spotting some
134 </I>><i>potential pitfalls which was my primary aim after you said you would not
135 </I>><i>consider fixing it. I am disappointed it will not be at least an option in
136 </I>><i>the main services package, but, since I already have to patch in odd things
137 </I>><i>anyway, it is just one more for the list.
143 </I>><i>------------------------------------------------------------------
144 </I>><i>To unsubscribe or change your subscription options, visit:
145 </I>><i><A HREF=
"http://www.ircservices.za.net/mailman/listinfo/ircservices">http://www.ircservices.za.net/mailman/listinfo/ircservices
</A>
153 <LI>Previous message:
<A HREF=
"002860.html">[IRCServices] /ns ghost exploit
155 <LI>Next message:
<A HREF=
"002862.html">[IRCServices] Services Admins and Opers?
157 <LI> <B>Messages sorted by:
</B>
158 <a href=
"date.html#2861">[ date ]
</a>
159 <a href=
"thread.html#2861">[ thread ]
</a>
160 <a href=
"subject.html#2861">[ subject ]
</a>
161 <a href=
"author.html#2861">[ author ]
</a>
projects / irc.git / blob