The Lua sandbox - is it necessary?

There have been various posts complaining about the Lua sandbox, and how it interferes with attempts by genuine scriptwriters to provide a good experience for their players.

I'll start by repeating what I said in another thread recently:



We hear daily reports about security problems with Windows, and how accounts are stolen or compromised, due to ineffective security.

It seems bizarre to me to be arguing for the removal of the sandbox, which effectively gives anyone who convinces a player to load a plugin complete control over their PC.

Sure, we may get less complaints about having to do a few extra steps to get a plugin to work, but how about the extra complaints that their entire character was hacked and all their gear stolen?

I can see there are a couple of issues however. One is that some other languages (like VBscript) are not sandboxed and thus in themselves represent a security threat.

Another is that, if you are going to trust MUSHclient, you may as well trust at least some plugin writers, like ones who post here frequently, and have a good reputation.

So rather than arguing that since the back door lock is broken, we may as well leave the front door unlocked as well, perhaps we can address the real issues.

The insecurity of VBscript and other WSH languages

This could be addressed by making the default to not allow those script languages at all (effectively sandboxing them out of existence). Then you would have to make a conscious decision to allow one. So for example, if you download a Python plugin, the player has to actively approve its use. There could be a message "warning - this script language gives uncontrolled access to your PC - do you want to allow this?".

The annoyance of installing plugins from trusted players

This could be addressed by some sort of trust system (like security certificates from web sites). I'm hazy on how the details would work, but some sort of certification process that a trusted writer (eg. Twisol, Worstje) could easily generate, but that an unknown writer could not. Then MUSHclient could have a list of trusted script-writers that are automatically allowed to have plugins installed, including bypassing the existing sandbox.

These trusted certificates could be:

• Pre-installed; or
  
• Installed once per author when required; or
  
• Checked by querying the mushclient.com web site in some way (say, once per certificate)

---

I should mention in passing that I personally use the sandbox for other purposes than just security. For instance, if I put in it:



Then every world automatically has access to the tprint utility without it having to be loaded every time I want to check out a table.

Put simply, despite its benefits to users of Lua plugins, it has a serious usability problem in that the user has to dig around in some obscure area, find the plugin's ID, find their world's ID, and edit them in. If the usability problem were addressed - i.e. a list dialog much like the trigger/alias/etc list, containing "trusted" plugins and their permissions - there wouldn't be nearly as much griping.


I've mentioned fixing the usability issue before, and there was no interest. Obviously it would be better to extend the security we have, but in lieu of making it less than a major hassle...


This seems like an excellent and seemingly easy security measure to introduce.



This is also a good idea, but I'm similarly hazy on the details...



I usually add that to my script file instead, but then I have very few worlds. I have a suggestion for making script file usage easier, but that's for another thread.

I too use the sandbox for a global require header... and have deleted all the security precautions it usually grants.

I think the main difference between your Microsoft security comparison and MushClient is one of scope. Windows interacts with other systems in a myriad of ways; internet explorer runs so many plugins, and renders content from so many (ad spewing :( ) sources that Security is a big issue. HTTP requests are flying all over the place. You shouldn't discuss trade secrets in the middle of a football stadium during the game.

Mudding/Mushing is a niche practice these days, of that, MushClient has a moderate percentage of the userbase. Public Plugin authors are an even smaller percentage of that. (Worste, Twisol, Me... who else makes plugins that are "in the wild?" Hell, even my plugins are typically specific to 3 Kingdoms, and my character's name is all over them). You can't write a plugin anonymously and have a drive-by-download trojan infect a users system. Mushclient interacts with the world in 3 ways: a Telnet socket to one specific server, sqlite, and the xml parser. Maybe it'd be possible to write a Melissa.vbs style macro virus without the whole self-propagation thing (oops, not a virus by definition then), but plugins for MC are either Globally distributed on this site, where we know you read the text of the xml and wouldn't let anything bad happen; or they're distributed through a community of mudders where your own reputation matters. It's like having a private conversation in your study (server connection) with your servants (plugins) around.

Is it good to be security conscious? Yes. Is the sandbox suffering from a little paranoia and delusions or grandeur? Yea, I think so too...

It's more like: The back door's lock is broken, but we live on Antarctica where our neighbors are our friends and penguins, so who gives a damn?


For years, smug Mac zealots would gloat that there were no viruses for Macintosh... the truth being that with only 7% market share, it wasn't worth the time to write a virus for the OS. Now that macs are trendy, and iOS has a substantial market share... There are (a few) viruses on mac! woo hoo


As pointed out... There's still access to the WSH languages, without a sandbox... So, Those Evil Machiavellian Bastages out there twisting their mustaches and determined to find a way to use MC to begin their nefarious plans for world domination, identity theft, and AdWords-click-fraud won't be thwarted because of Lua's sandbox. It's a false sense of security.

Everything I wanted to say has already been said, or re-iterated from a point I made in another thread. That said, I am very glad there is a serious discussion on the subject now.

To take the paranoia thing a step further - has zmud/cmud ever have trouble of malicious scripts? To my knowledge, those programs have zero security precautions, and to my knowledge have at least triple the userbase that MUSHclient has. (Disclaimer: 93% of statistics are made up on the spot.)

Is being security-minded good? Very.
Is it good to give off a false sense of security? Nope.

To put WillFa's example of the broken backdoor lock in another light... When your backdoor lock is broken, and everyone knows it is broken, what point do the triple bolts and chain on your front door serve?

Now I think Nick said stuff about making it harder to use plugins scripted in other languages. That, in my eyes, is once more giving a false sense of security.

1) Are you making it a global check, or a per-plugin one?
2) How would it interact with existing scripting calls like LoadPlugin?
3) How does it defend one from the idiotic user? 99% of players know nothing of scripting, and if they want a plugin, and someone or some page tells them to hit ALLOW, they will do it without as much as reading the warning.

The last point touches upon social engineering, which is an all-around problem that even Microsoft can't properly fix, because the entire approach is to have the user tricked into turning off those things that protect against the malicious aspects in the first place.

Now, since my post is already all over the place with arguments anyway, I'll add another unrelated one to the mix. Usability.

MUSHclient has long suffered from usability issues. It is why a lot of people I know keep going back to zmud because MUSHclient is confusing, difficult, and hard. And I don't blame them. Besides the fact that all the configuration screens need a really good cleanup, the one thing that is relatively easy (installing plugins) is now proposed to be made even more difficult.

Any extra security precaution you put in place has to be balanced with the common usage. There is a reason that Microsoft tuned UAC to popup far less in W7 compared to Vista, because it showed up so often that people just hit OK all the time to get rid of it. It beat its own purpose.

Just read the other topic, and quoting a post here to answer it to prevent pulling that topic further off-topic:



At the cost of a lot of features. Lua does not support proper threading, for one. Nor does Lua have the batteries-included mindset that Python for example operates by. Of course, you can go find all the different libraries you need, supply them with your plugin, and do things that way, but even then you don't take into account that Lua is not suitable for every script out there. Threading, unicode, hell, downloading a file from a webserver into memory as the other topic had discussed... one would need LuaSocket for that, which would require allowing DLLs to be loaded.

As a 'less complicated' alternative as I think you called it, I would have to disagree. Sending over binary files through telnet negotiation is a plain wrong idea. What if at some point I wanted to start offering backgrounds to go with different areas? Those might quickly reach into 100kb to avoid noticable jpeg artifacts. Besides inventing yet another protocol to transfer files, it lacks the ability to grow into future requirements: 100kb would for a lot of people mean a lot of noticeable delay while it was downloading.

(Ended up crossing the subjects a bit after all. Sorry about that.)

Is Lua a nice language? Sure, it has its appeals. Can it replace all the other languages? No way. A good example I just thought of are our blind users, who use screenreaders which generally interact through COM. Lua can't do COM, so VBScript is the way there.

That makes sense. But if you do that for VBScript, etc, couldn't the same approach be extended to the Lua sandbox?

For example, if my Lua plugin requires io, then instead of the current sandbox error message it would just display the above warning message and ask the user if they're willing to trust the plugin.

If this was only done when the plugin was added, it wouldn't be much hassle for the user - just an extra click when they first set it up.

Well that's quite a good idea. If the trusted plugins were saved (like in a database) then once you trust them once they become trusted for all worlds.

I was trying to think of an easy way to trust *authors* however that wouldn't be simply circumvented by someone claiming that they were Worstje and therefore should be trusted.

I was making humorous counter to the suggestion that if the sandbox isn't working quite right, just get rid of it.

A fairly common way of handling this is with PGP signing of some sort. Give a trusted author a private key and have them sign the plugin source with it; MUSHclient (or anybody, really) has a public key that verifies that the signature matches.

So, only people with the private key can mark the plugin as being truly theirs.

A side effect, perhaps a feature, is that if somebody modifies the script even just a tiny bit, the signature will no longer check out and the plugin will need to be signed again.

This lets you give a private key to people you think are reasonable and not going to write malicious plugins, and it lets users use such plugins out of the box. You could still have the sandbox for all other plugins.

I suspect this wouldn't work for my structured plugins, since they're implemented across multiple files.

You raise a very good point. Before I get too worked up about trusting plugins, we need to think about what a plugin might load. For example, someone could take a trusted plugin that calls (say) copytable.lua and replace copytable.lua with something that does a lot of harm.

So then the trust would have to extend to modifying how "require" works (and "package.loadlib", and "dofile" etc.)

---

The simplest thing (and which also addresses useability somewhat) is to simply distribute an entire packaged-up installer. This would include a modified sandbox, whatever plugins you want, pre-installed, various settings already configured, images pre-loaded, sounds pre-loaded, etc.

Aardwolf did this a while back (before miniwindows) and I believe are looking at doing it again with a more recent version.

Most of the posters here are interested in only a MUD or two, and it wouldn't be too hard for you to make up a pre-installed package (in fact I have a posting somewhere about how to do that).

And remember, once you have your pre-made package, players can install upgrades over it, as they don't replace the sandbox.

I was looking at that, and how to build that functionality into MUSHclient somehow. If it wasn't there, I bet no-one would use it (they would just trust things automatically). It would be better to have the client automatically trust at least some stuff.

But building in the PGP (or GPG) functionality would be quite a lot of work, and then you would need to explain how to get trusted certificates etc.

Building in a custom version (ie. do the maths myself) might be simpler in some ways, but then we hit the issue that Twisol raised, that in some cases at least, it isn't just a single file you have to trust.

Sorry, seems the funny totally escaped me. Glad to hear it was a funny tho. :)

With regards to the signing... it sounds very interesting. The multiple files issue is a problem though, since even if you were to do a Lua solution (which is very viable, merely a matter of replacing the require/dofile mechanisms), it wouldn't solve the issue for other plugins.

Although something like signing the primary file, and having that one contain CRCs to the other files needed might suffice. The only issue then would be that one would need to keep the latter list updated. A seperate 'plugin signing' tool would seem useful then.

But I think we are getting carried away a bit. Let me sum up what direction I think the discussion is heading in:

* All plugins (any language) not trusted by default.
* 'Trustedness' gets stored per-plugin, regardless of world, thus persisting past unloads.
* Plugins can be signed so they can be automatically trusted using a PGP-like algorithm.
* To account for multiple files being in a plugin, the plugin file would need to be able to contain checksums (MD5, CRC32, whatever) of other related files that would need to check out as well in order to be trusted.
* The latter features would likely need some kind of 'signing' tool to take an (un)signed plugin, and sign it or update it because changes have been made. (Latter to avoid having to pick the files to checksum every single time.)

Anything I am forgetting thus far?

You've got it, although I am starting to think all that effort isn't really worth it.

Why is it a problem? The files are all signed with the same private key, you have the public key for one therefore for all, so multiple files really doesn't make a difference. Presumably, if you trust a plugin, you also trust things it might load (and there's no reason why things it loads wouldn't be subject to the same security mechanism).

David, that would totally beat the point. Take Twisol's basic plugin structure thing, where has scripts seperated into modules, resources and whatever else it might need. The actual plugin file is little more than a basic script to set some stuff up, which then hands off all control to a main.lua script file. With all the scripting being in there, what is to stop a nefarious creature like myself (^_^) from wiping that file clean, replacing it with bad mojo, and putting it out there as a mirror of Twisol's wellknown SuperDuperStuffEveryoneWants plugin.

If only the plugin file gets verified, the above scenario would work, thus making the 'trust' system leaky as hell.

You still have the problem that:

No system is 100% secure.

Trying to implement something that covers 80% of the threats lulls the user into a sense of security and doubly exposed to the 20%.

No matter what you do, you can't protect a lUser from everything out there. Isn't it better to teach them to be wary of everything and think, decide, and choose for themselves. Forget trying to protect; don't coddle; educate.

And if they don't care, why should we?




And I still think that a lUser is either going to export a bunch of triggers to a plugin so they don't have to look at them, or a buddy on the mud they play will tell them where to find a nifty plugin that Zoltan the Ubergoober, an established character in their community, wrote. Not just download stuff randomly.


Seriously Nick, you get bugged by a bunch of us wanting you to look at our code (hey, we look up to you, it's a compliment). How many people are distributing plugins anyway?

Ah... you might have missed this somewhat important and perhaps relevant sentence :-)


I'm not sure how I feel about the sandbox discussion in the first place, and the above mechanism might be trying to solve a social problem by technical means, but so far there is no technical issue with it.

David, I don't see how it is technically possible to put files a script requires (or imports in Python terms) through the same security mechanism. While one can replace the Lua variety, the same honor is not shared with Python and co. And even then one would need to figure out a format to modify all the files to include such signing information.

I don't see any viable cross-language alternative other than signing the plugin file, which contains hashes of all other files as a means of validating them.

Of course, I am still a fan of wiping the sandbox clean by default, and probably adding a 'Secure Lua' option to the dialog which puts in the current sandbox code for people who are really paranoid.

Then again, one might argue that beats the point of the sandbox, but as it is, I feel it beats its own purpose already. :)

It has already been stated that the other scripting languages are essentially insecure anyhow, no matter how you look at it as soon as you load them, so I was assuming that we were still operating under that world......

Besides, this all comes down to a trust issue anyhow. The so-called structured plugin approach is basically a bad one when it comes to security.
You can never completely prevent users from shooting themselves in the foot. If they want to download the ZomgAwesomeTrustedPlugin by Twisol but go to the BwahahaEvilSite by Worstje... well... yeah.

That said, you could introduce a script function such that loader scripts can pass loaded files through the same old signature mechanism. I don't know if WSH lets you overwrite the __import__ implementation in Python, for example, but if you could, all of this becomes very easy for Python.

OK, well I have to say Twisol tipped me over the edge, so to speak, when he correctly pointed out that the issue is not so much with plugins (although that is indeed a major issue), but with plugins that have to load other files.

Once we agree that a sophisticated, useful, plugin is likely to contain things like extra files, DLLs even, maybe "pre-installation" things to do (just run my Setup.exe), it is going to be hard or impossible to make it all secure.

All it takes for a malicious person to do is convince the player to install his plugin (written in, say, Perl) and click through any warnings about unsigned files.

In fact, this happens all the time. You buy a new printer, and the driver installations instructions say "you may get a warning about an unsigned driver, just say OK". People are used to it.

So I am inclined to agree now that the sandbox is an annoyance more than anything else.

How is this for a compromise? Instead of getting rid of it, we simply shift, for future releases, the default. The default would be to trust all worlds and all plugins, and allow DLLs to be loaded.

This effectively makes Lua as secure (or insecure if you like) as all the other script languages.

Now anyone who is worried about security can just switch the "trust all plugins" back to false (or more simply, not install plugins they don't trust in the first place).

In fact, because of that last idea (if you are worried, don't install plugins) this may mean the sandbox could just be blanked out, and maybe a comment put there that if you want, you can install <suggested code> from this web site.

To be honest, I think security has to be built in from the ground up. Once you have virtually unlimited script engines you can install, it is going to be a very hard task to make it totally secure, and someone that wants to will find the least secure part (and who knows what that is?) to launch their attack.

Just as an aside, World of Warcraft has a somewhat more secure scripting environment (even though it is Lua). As far as I can see they compiled Lua into the executable (rather than using a DLL, so you can't just swap to a different DLL), don't allow other script languages, don't allow things like file access (and loading DLLs), and have some system of trusted paths (to defeat bots). From what I have read, the Lua code is considered trusted until it hits the user-written portion, and then it becomes untrusted. The untrusted code has restrictions on it to make botting harder.

However none of that would work here, for one thing the client source is publicly available, and for another there would be screams of protest if we tried to get rid of all the other scripting languages, permanently.

Thanks for the compliment. And of course I didn't think you guys would be the problem. It would be someone we haven't heard of. But that someone could just as easily say something like "I have a new great mapper, just run MyMapper.exe to install it", thus bypassing any sort of security we might have at the MUSHclient end.

This sounds great to me!



I completely agree. Security has to be considered from the absolute beginning.

Nick basically affirmed what I suggested in my final post, so yeah, I'm in full favor of such changes myself. Usability ftw! :)

OK changed to make the non-intrusive sandbox the default in version 4.57.

Note that existing sandboxes will not be affected.

That describes how to disable existing sandboxes.

That post is also available through the shortcut link:

http://www.gammon.com.au/security

While I agree with the solution of removing the sandbox, I wanted to point out that the above problem is not a problem for Lua scripts. So, to be somewhat persnickety here, the tipping point should not have been Lua scripts loading other Lua scripts, but rather the existence of other (inherently insecure) languages in the first place. (The signing scheme I discussed can make sure that the trust mechanism extends to loaded Lua scripts, in this event by overwriting how 'require' works. Note that I believe you can do the same thing in Python, by overwriting the __import__ built-in function.)

Well, I didn't mention the word Lua in the bit you quoted.

I was about ready to try to trust plugins in all languages when I realized that the problem was not so much the primary plugin, but the fact that each language would almost certainly allow you to load secondary files. For example, this old post shows how you can "include" files into VBscript:



So, to solve the problem, you would have to somehow stop (or intercept and then apply trust rules to) inclusion of other files, execution of DLLs, and so on, for every known language. Now my knowledge of Perl, Python, PHP, Ruby, TCL, and so on, is not great enough to be able to do that reliably. In fact, it isn't so much the core language (in itself quite a challenge) but the implementation under the Windows Script Host that would need to be examined.

Even under Lua, you have the functions "require", "dofile", "loadfile", "package.loadlib" to intercept.

On top of all that, even if done, someone could almost certainly "human engineer" you to bypass the trust by saying something like "oh just click Yes when asked if you need to trust file X - that is known bug in the client".

Sure; I was just saying that the previous state of the world (where Lua was the only one with security) could have been preserved while making Lua plugins trusted; others would be left as-is. This is assuming that "some security in Lua is better than none anywhere", which appeared to be your previous position -- the Lua trust solution helped preserve this.


Yes, I don't think the social problem can ever really be solved technically. This is the bane of all computer security problems, really. :-(

I have moved from trying to defeat them by technical methods (and so far, admittedly, there have been no reported cases of problems) to making positive suggestions on how to identify trusted plugins.

http://www.gammon.com.au/security

If you follow the guidelines there, both in who to trust, and who not to trust, you should be reasonably safe from people trying something funny. Of course, nothing is perfect.

I am also modifying the "banner" shown when MUSHclient starts up to mention a link to that page, so that people who don't frequent the forums can quickly find suggested ways of "staying safe".