Login
User Name:

Password:



Register

Forgot your password?
Changes list / Addchange
Author: Khonsu
Submitted by: Khonsu
6Dragons mp3 sound pack
Author: Vladaar
Submitted by: Vladaar
AFKMud 2.2.3
Author: AFKMud Team
Submitted by: Samson
SWFOTEFUSS 1.5
Author: Various
Submitted by: Samson
SWRFUSS 1.4
Author: Various
Submitted by: Samson
Users Online
There are currently no members online.

Members: 0
Guests: 25
Stats
Files
Topics
Posts
Members
Newest Member
488
3,788
19,631
595
Khonsu

Today's Birthdays
There are no member birthdays today.
» SmaugMuds » General » General Discussions » IMC2
Forum Rules | Mark all | Recent Posts

IMC2
< Newer Topic :: Older Topic >

Pages:<< prev 1, 2 next >>
Post is unread #1 Nov 10, 2006 6:47 pm   Last edited Nov 10, 2006 8:05 pm by Kigen
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
Ok, who in the hell was abusing their powers on IMC2?

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

Post is unread #2 Nov 10, 2006 7:11 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

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.

Post is unread #3 Nov 10, 2006 7:59 pm   Last edited Nov 10, 2006 8:07 pm by Kigen
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
I have a fix for the nameless 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.

Post is unread #4 Nov 10, 2006 11:45 pm   
Go to the top of the page
Go to the bottom of the page

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

Post is unread #5 Nov 11, 2006 12:00 am   
Go to the top of the page
Go to the bottom of the page

Conner
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?

Post is unread #6 Nov 11, 2006 12:17 am   
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

 
It will work, and server is a better approach.

Post is unread #7 Nov 11, 2006 12:35 am   
Go to the top of the page
Go to the bottom of the page

kiasyn
Magician
GroupMembers
Posts121
JoinedJun 30, 2006

 
not sure, but Kigen you'll want the can_forward function in imc.c (in the liberty server)

Post is unread #8 Nov 11, 2006 9:44 am   
Go to the top of the page
Go to the bottom of the page

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

Post is unread #9 Nov 11, 2006 2:03 pm   
Go to the top of the page
Go to the bottom of the page

Conner
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?

Post is unread #10 Nov 11, 2006 2:52 pm   
Go to the top of the page
Go to the bottom of the page

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

Post is unread #11 Nov 11, 2006 9:10 pm   
Go to the top of the page
Go to the bottom of the page

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

Post is unread #12 Nov 13, 2006 9:40 pm   Last edited Nov 13, 2006 9:44 pm by Kigen
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
In imc.c, function can_forward, after the check for "channel=15" (and return from it) add this.
      /* 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.

Post is unread #13 Nov 13, 2006 10:23 pm   
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,685
JoinedJan 1, 2002

 
Yeah. Lets try tagging them first before dropping without warning.

Post is unread #14 Nov 14, 2006 6:18 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
What kind of warning do you want done Samson?

Post is unread #15 Nov 14, 2006 7:07 pm   
Go to the top of the page
Go to the bottom of the page

Conner
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". :wink:

Post is unread #16 Nov 14, 2006 8:30 pm   
Go to the top of the page
Go to the bottom of the page

Samson
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 :)

Post is unread #17 Nov 14, 2006 9:02 pm   
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

 
Oh, goody! We still get to include my shock therapy for someone. :grinning:

Post is unread #18 Nov 16, 2006 1:14 pm   Last edited Nov 16, 2006 1:22 pm by Kigen
Go to the top of the page
Go to the bottom of the page

Kigen

GroupMembers
Posts38
JoinedNov 3, 2006

 
Oh goodie. Let me figure out how to reform the packet to include the Sent by stuff. :P

Also, Samson, do you want me to make it spit out something into the logs when someone does this? Like a warning or something?

Post is unread #19 Nov 16, 2006 1:20 pm   
Go to the top of the page
Go to the bottom of the page

Kigen

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

Post is unread #20 Nov 16, 2006 3:44 pm   
Go to the top of the page
Go to the bottom of the page

Conner
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. :smile:

Pages:<< prev 1, 2 next >>