software/RELEASES/ircservices/achurch.org/services/lists/ircservices/2002/002860.html

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