projects / irc.git / blame
| Commit | Line | Data |
|---|---|---|
| 3bd189cb JR |
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="002860.html"> | |
| 11 | <LINK REL="Next" HREF="002862.html"> | |
| 12 | </HEAD> | |
| 13 | <BODY BGCOLOR="#ffffff"> | |
| 14 | <H1>[IRCServices] /ns ghost exploit</H1> | |
| 15 | <B>Andrew Church</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">achurch at achurch.org | |
| 18 | </A><BR> | |
| 19 | <I>Fri Mar 15 16:19:00 PST 2002</I> | |
| 20 | <P><UL> | |
| 21 | <LI>Previous message: <A HREF="002860.html">[IRCServices] /ns ghost exploit | |
| 22 | </A></li> | |
| 23 | <LI>Next message: <A HREF="002862.html">[IRCServices] Services Admins and Opers? | |
| 24 | </A></li> | |
| 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> | |
| 30 | </LI> | |
| 31 | </UL> | |
| 32 | <HR> | |
| 33 | <!--beginarticle--> | |
| 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. | |
| 38 | ||
| 39 | --Andrew Church | |
| 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> | |
| 42 | ||
| 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)? | |
| 50 | </I>><i> | |
| 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. | |
| 58 | </I>><i> | |
| 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. | |
| 67 | </I>><i> | |
| 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. | |
| 74 | </I>><i> | |
| 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 | |
| 81 | </I>>><i> them. | |
| 82 | </I>><i> | |
| 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 | |
| 85 | </I>><i>nicknames. | |
| 86 | </I>><i> | |
| 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. | |
| 92 | </I>><i> | |
| 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. | |
| 102 | </I>><i> | |
| 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. | |
| 107 | </I>><i> | |
| 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. | |
| 113 | </I>><i> | |
| 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. | |
| 117 | </I>><i> | |
| 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. | |
| 126 | </I>><i> | |
| 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. | |
| 130 | </I>><i> | |
| 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. | |
| 138 | </I>><i> | |
| 139 | </I>><i>-- | |
| 140 | </I>><i>Mark. | |
| 141 | </I>><i> | |
| 142 | </I>><i> | |
| 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> | |
| 146 | </I> | |
| 147 | </PRE> | |
| 148 | ||
| 149 | <!--endarticle--> | |
| 150 | <HR> | |
| 151 | <P><UL> | |
| 152 | <!--threads--> | |
| 153 | <LI>Previous message: <A HREF="002860.html">[IRCServices] /ns ghost exploit | |
| 154 | </A></li> | |
| 155 | <LI>Next message: <A HREF="002862.html">[IRCServices] Services Admins and Opers? | |
| 156 | </A></li> | |
| 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> | |
| 162 | </LI> | |
| 163 | </UL> | |
| 164 | ||
| 165 | </body></html> |