IMC2
< Newer Topic
:: Older Topic >
#1 Nov 10, 2006 6:47 pm
Last edited Nov 10, 2006 8:05 pm by Kigen
GroupMembers
Posts38
JoinedNov 3, 2006
Ok, who in the hell was abusing their powers on IMC2?
I didn't do any of those actions.
This was found to be Zeno@SmaugInstitute.
I found it via this line during the early part of my patch.
Zeno@SmaugInstitute [ichat] Eldrard@DarkNightMares: Hi
He used the nameless social to fake to be Eldrard@DarkNightMares.
[ichat] You slam your head with a REALLY Giagantic Sledge hammer.. WTF are you t
hinking??
<32000hp 100m 740mv>
[ichat] You tap your foot impatiently.
<32000hp 100m 740mv> ichat WTF
<32000hp 100m 740mv>
[ichat] Kigen@DBBZ: WTF
<32000hp 100m 740mv> ichat Who is abusing power?
<32000hp 100m 740mv>
[ichat] Kigen@DBBZ: Who is abusing power?
<32000hp 100m 740mv>
[ichat] You cut your head off, deciding your life sucks.
<32000hp 100m 740mv> ichat #### IMC
<32000hp 100m 740mv>
[ichat] Kigen@DBBZ: #### IMC
<32000hp 100m 740mv> imcdisconnect
I didn't do any of those actions.
This was found to be Zeno@SmaugInstitute.
I found it via this line during the early part of my patch.
Zeno@SmaugInstitute [ichat] Eldrard@DarkNightMares: Hi
He used the nameless social to fake to be Eldrard@DarkNightMares.
#2 Nov 10, 2006 7:11 pm
GroupMembers
Posts38
JoinedNov 3, 2006
I have found out what was doing that.
It appear IMC bases the socials on the mud's database of them, so if I mud does,
sedit testimc create
sedit testimc onoarg IMC sucks ****!
They can make it appear as a announcement of such and not show who sent them.
It appear IMC bases the socials on the mud's database of them, so if I mud does,
sedit testimc create
sedit testimc onoarg IMC sucks ****!
They can make it appear as a announcement of such and not show who sent them.
#3 Nov 10, 2006 7:59 pm
Last edited Nov 10, 2006 8:07 pm by Kigen
GroupMembers
Posts38
JoinedNov 3, 2006
I have a fix for the nameless socials.
This was developed on the IMC2 Freedom Client.
Find:
Replace with:
Find:
Replace with:
Save and compile.
Smile, now you will absolutely know who is sending those socials, this also prevents people from faking to be someone they are not by modifying the coloring with socials.
This was developed on the IMC2 Freedom Client.
Find:
char buf[LGST], name[SMST];
Replace with:
char buf[LGST], name[SMST], tbuf[LGST];
Find:
else snprintf( buf, LGST, c->socformat, txt );
Replace with:
else { // Fix by Kigen. if ( !strstr( txt, from ) ) snprintf( tbuf, LGST, "%s sent: %s", from, txt ); else snprintf( tbuf, LGST, "%s", txt ); snprintf( buf, LGST, c->socformat, tbuf ); }
Save and compile.
Smile, now you will absolutely know who is sending those socials, this also prevents people from faking to be someone they are not by modifying the coloring with socials.
#4 Nov 10, 2006 11:45 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
A good effort, but mostly useless since it's a client side fix. If this issue is really a big sore spot then it would have to be fixed at the server level where the packets aren't as easily manipulated.
However, there's nothing you can do to positively verify the identity of anyone using the IMC2 connection. The code is alterable at the mud level and out of anyone's real control. If someone is determined to, they'll be able to masquerade themselves no matter what measures are taken on the server.
If you'd like to look over the server code and suggest a place there to try and fix this, I'd be more than happy to take a look at it. It would have the advantage of being effective on all connected clients and not require them to make alterations.
However, there's nothing you can do to positively verify the identity of anyone using the IMC2 connection. The code is alterable at the mud level and out of anyone's real control. If someone is determined to, they'll be able to masquerade themselves no matter what measures are taken on the server.
If you'd like to look over the server code and suggest a place there to try and fix this, I'd be more than happy to take a look at it. It would have the advantage of being effective on all connected clients and not require them to make alterations.
#5 Nov 11, 2006 12:00 am
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
So, are you saying that the aforementioned client side fix won't work, or just that doing it on the server is a much better approach?
#6 Nov 11, 2006 12:17 am
Magician
GroupMembers
Posts121
JoinedJun 30, 2006
It will work, and server is a better approach.
#7 Nov 11, 2006 12:35 am
Magician
GroupMembers
Posts121
JoinedJun 30, 2006
not sure, but Kigen you'll want the can_forward function in imc.c (in the liberty server)
#8 Nov 11, 2006 9:44 am
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
Conner said:
So, are you saying that the aforementioned client side fix won't work, or just that doing it on the server is a much better approach?
The fix will work, but it's only viable if people actually add it to the code or upgrade to a client that already has it. Retroactively it's not very useful and you can't force anyone to apply it.
Adding the protection at the server level at least takes manipulation control out of the hands of those who are doing this, and instead puts the "burden of trust" on the ones operating the servers.
And it should be noted that this "exploit" has existed since the beginning of imc. It's not a threatening thing.
#9 Nov 11, 2006 2:03 pm
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
No, it's clearly not threatening, just annoying primarily but it also gives folk an easy way to spoof others, so it'd be nice to be rid of it. Otherwise, I can easily see where your coming from. So, since it appears that Kigen is looking into finding a solution server-side for this, the next question is would adding this fix to a client conflict with a fix applied to the server later?
#10 Nov 11, 2006 2:52 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
It may not conflict, but there's a possibility it could get double filtered. If/when Kigen submits a fix for the server code I sure as hell won't be trusting the client side fix to be accurate. You could slip anything into the "sent by" field he's tagging to it. There's no constraint on what could end up there. The client side fix will only deter casual users and non-coders from getting around it.
#11 Nov 11, 2006 9:10 pm
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
Are we trying to deter coders and non-casual users with this measure? I imagine that no matter what's done, someone determined enough will still be able to bypass it particularily with code level access.
On the other hand, would double filtering have any real detriment? (I'm trying to decide whether or not it's worth throwing this client side fix in and whether or not it'd mean pulling it back out once the server-side fix is in place.)
On the other hand, would double filtering have any real detriment? (I'm trying to decide whether or not it's worth throwing this client side fix in and whether or not it'd mean pulling it back out once the server-side fix is in place.)
#12 Nov 13, 2006 9:40 pm
Last edited Nov 13, 2006 9:44 pm by Kigen
GroupMembers
Posts38
JoinedNov 3, 2006
In imc.c, function can_forward, after the check for "channel=15" (and return from it) add this.
It is untested Samson, so you might wanna do a little testing first.
As you can see, I have it just drop the packet when someone attempts this. I could alter it to add something to the text field.
/* Check for validy of emote packets. - Kigen */ if( p->data.str().find( "emote=2" ) != string::npos ) { unsigned int i, e; string tbuf; i = p->data.str().find( "text=" ); if ( i == string::npos ) return false; e = p->data.str().length(); tbuf = p->data.str().substr( i, e ); if ( tbuf.find( p->from ) == string::npos ) return false; }
It is untested Samson, so you might wanna do a little testing first.
As you can see, I have it just drop the packet when someone attempts this. I could alter it to add something to the text field.
#13 Nov 13, 2006 10:23 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
Yeah. Lets try tagging them first before dropping without warning.
#14 Nov 14, 2006 6:18 pm
GroupMembers
Posts38
JoinedNov 3, 2006
What kind of warning do you want done Samson?
#15 Nov 14, 2006 7:07 pm
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
Something simple, like when someone tried to mask their identity, it sends a small electrical charge (say 12 volts at 30 ampres) through their keyboard directly to their fingertips with a flashing message centered on their screen stating "don't do that again".
#16 Nov 14, 2006 8:30 pm
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002
Just some kind of message tag, like [Sent by: %s@MUD] where %s should be obvious, and MUD being where the packet actually came from.
We can leave the electric shock treatment for the repeat offenders
We can leave the electric shock treatment for the repeat offenders
#17 Nov 14, 2006 9:02 pm
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
Oh, goody! We still get to include my shock therapy for someone.
#18 Nov 16, 2006 1:14 pm
Last edited Nov 16, 2006 1:22 pm by Kigen
GroupMembers
Posts38
JoinedNov 3, 2006
Oh goodie. Let me figure out how to reform the packet to include the Sent by stuff.
Also, Samson, do you want me to make it spit out something into the logs when someone does this? Like a warning or something?
Also, Samson, do you want me to make it spit out something into the logs when someone does this? Like a warning or something?
#19 Nov 16, 2006 1:20 pm
GroupMembers
Posts38
JoinedNov 3, 2006
Conner said:
Are we trying to deter coders and non-casual users with this measure? I imagine that no matter what's done, someone determined enough will still be able to bypass it particularily with code level access.
On the other hand, would double filtering have any real detriment? (I'm trying to decide whether or not it's worth throwing this client side fix in and whether or not it'd mean pulling it back out once the server-side fix is in place.)
To answer this old question, I will make sure that the patches won't double filter. What I'm basically looking for with the client side patch is the name in the text field. And with what Samson is wanting me to do is add the name to the text field, but instead of clientside, he wants me to add it server side. Either way, it won't double filter unless someone malforms the from field so it is different from what the IMC server is seeing as who it is from. (i.e., it won't double filter if both the IMC server and the client have the same "from." )
#20 Nov 16, 2006 3:44 pm
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005
Thanks, Kigen, as it is I went ahead and installed your fix based on Samson's response, but I do appreciate the bit of enlightenment that you've given in that last post. It helps me to better understand what you and Samson have been discussing as well as reassuring me that I did not make a mistake in tossing in your fix. (Not to mention offering the consolation that I won't need to remove that fix once the server-side fix is in place.