Zugg Software :: View topic

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

Zmud allows you to do an alias something like this:
dj

shout %proper( %1) , %proper( ",")

The %proper(",") makes a cls to all players with zmud that see the shout (the screen is cleared with a black screenshoot). This can be used malintencionatly for a player to attack other players and no be visible to that attacks.
Please, can you say me how can I block this in the MUD code so players playing with zmud are not abused? Also, can you repair and block that action?
I've tried to block the 27[H27[2J but it seems not working so I sopose is other thing.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

You should probably talk to your MUD's immortals, particularly the coder. I don't see any reason to allow shouts to contain CTRL-L (form feed) or any other CTRL character.

I can't think of any way to block this at the client end.

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

I'm the immortal and I need to know what it's being send.
I will investigate by my own to discober what code it's being send, but as it only seems to affect zMUD I think the client would be interested in block this code by his own, so other MUDs could not be striping it.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The %proper(",") is producing ascii 12, as Lightbulb said formfeed. While it is a bug for %proper to produce such output the same affect could be achieved by a user doing %char(12). Your mud should strip all characters less then 32 from user input. They are all control codes. Sadly these control codes only affect zMud users because zMud is the only client that properly implements the specifications for these codes.

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

Yes, after investigating a little I've discovered that carac '12' makes the cls.
But since it's only a problem for zMUD users, I think I don't want to waste MUD cpu in stripping that character so I suppouse people can use a trigger or something to ignore lines with that character.
Do you know the zmud command to ignore a line? so I can tell all zmud users to use that trigger if they don't want to be vulnerable to that character.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

In zMud checking the preference "Display control codes" under General|Emulation will solve this particular character problem, however it will break certain control codes sent from the mud.

Again the correct way to do this is to strip all such control codes from user input, since any other client that properly implements the usage of these codes will be affected. Another consideration is a user placing such a code directly into thier character name. Perhaps the odd ansi sequence would affect more clients, or worse yet an IAC sequence would affect nearly every client. That is why I say it should be done right on the mud side.

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

There's no problem with names since they are checked when the character it's created. And the problem to strip it's that it have litle impact in the MUD since players send a lot of commands per second to the MUD especialy when there are 60-100 playerss connected simultanously and then I think that spend such litle CPU it's not necesary as we can punish that activity if someone abuse it.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

It's always disappointing to hear a head immortal declare that it's not worthwhile to implement his MUD correctly. However, a word to the wise is sufficient and I thank you for advising the zMUD community that your MUD doesn't welcome them.

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

I'm only declairing that zMUD users had a bug on his client. I'm a zMUD user and I've had encouraged the use of this advanced client implementing MXP and MSP, and lot of users have buied a zMUD license thanks to that, so I don't understand your words.
I'm only answering for a trigger that helps zMUD users to be protected to this abuse, so sadly my MUD can't be parsing all characters to avoid this as actually I can't touch the driver and perform this in LPC is a bad idea. So if I wan't to do that I've to wait to have the tools I'm demading to my machine administrators to recompile the driver.
I think I'm not demanding so much to zMUD comunity, only a trigger to avoid this until we can code the thing as it's needed.

MASTER Joined: 28 Nov 2000 Posts: 4817 Location: USA

Although short, I thought my original response was quite explicit. I explained that your players were sending an ASCII control-code directly to other players, that that was a flaw in your MUD's design, and that it should be corrected on the MUD.

Vijilante further explained the problem and once again stated that you should be stripping control codes (ASCII characters 0-31). Your response was that if it only affects zMUD you don't think it's worth fixing.

quote:
But since it's only a problem for zMUD users, I think I don't want to waste MUD cpu in stripping that character...

That, in turn, prompted my response thanking you for informing us that zMUD users should stay away.

This isn't a bug in the zMUD client. This is the correct response to ASCII character 12, the FF control-code. The assignment of control-codes and the correct response to each of them was established several decades ago when ASCII was developed. Any client which doesn't respond in this fashion is incorrect or incomplete. I'm fairly sure that zMUD is not alone in responding correctly to ASCII character 12. Any generic telnet client will probably respond the same way.

The problem isn't the correct implementation of the ASCII control set. The problem is allowing players to send ASCII control codes directly to other players. If they can send FF (character 12) directly then they can probably also send ESC (character 27) directly, which means they can send ANSI sequences without server intervention (which affects almost all clients). Given the vast capabilities built into ANSI, including keyboard reassignment, this is a potential security hole which would make me view your MUD as entirely unsafe to visit.

The solution isn't to make zMUD, and other telnet clients, use an incorrect or incomplete implementation of ASCII. The solution is to prevent your players from sending control-codes directly to other players.

As I said above, I don't know of any way to block individual control-codes. They are intended to control the client. That's why they are called CONTROL-codes. They are normally stripped, and acted on, before the parser ever sees the input which makes it impossible for a trigger to have any effect. I don't consider disabling the entire control-set, via a preference intended only for troubleshooting, to be an acceptable solution (although it's probably essential, for security reasons, on your MUD).

I am very interested in finding a solution. I don't expect that yours is the only MUD with this problem. I sincerely hope that anyone holding an IMM position on any MUD will immediately investigate whether their MUD shares the problem and take immediate steps to correct it if it does. I don't think this can be solved at the client end. However, I don't think arguing about who has responsibility for fixing it, client or server, is productive. I have tried, unsuccessfully, to write a trigger which detects the FF character. If I can't even detect it, I'm sure I won't be able to block it. It's up to you.

Beginner Joined: 26 Dec 2002 Posts: 20 Location: Spain

Oks.
Start another time.
Now we know what it's the character to strip, 12, and other CONTROL codes as well. We can do this at the MUD code, but I think it's interesant to you as well to solve the bug on some functions that are using zMUD, I'm saying bug all the time not because it's well implemented to interpret control codes, I'm saying that because some functions are not doing what are espected and sending control codes -> %proper(",")
Now I now what it's causing that, char 12, and that was what I spected on the first message, know the reason and indicate that a function in zMUD was not doing what it was spected.

I'm sorry if my language was ofensive to you, but I'm not english speaker and I'm very language limited so I use words as I think in my language, spanish, and it could sound offensive for an english speaker, it wasn't my intention. I was saying only that the impact on the CPU of our machine would be higher than the impact of the caracter itself, as currently to implement the stript in LPC until we can touch the c++ code of the driver that it's the correct way.

I'm sorry as I see you have been very offended by this.