[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  The Lua sandbox - is it necessary?
The Lua sandbox - is it necessary?

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Pages: 1 2  

Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Thu 12 Aug 2010 (UTC)

Amended on Thu 12 Aug 2010 12:02 AM (UTC) by Nick Gammon

Message
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:

Nick Gammon said:

Many people will recall that Microsoft have come in for quite a bit of sledging because their operating systems are perceived as having security flaws. Unfortunately, good security and ease-of-use are quite often opposing design goals.

Earlier versions of Windows tried to make things easy for the end-user, but in the process arguably introduced potential security problems. More recently things have been tightened up, but you now have the counter problem that if people get used to hundreds of security warnings (and clicking on "OK - get on with it") then the usefulness of the warnings tends to go away too.

In the case of MUSHclient, I didn't want to get into the minefield of releasing software that could be easily used to compromise the end-user's PC, so in the case of Lua (over which I had some control), there were two levels of security introduced:


  • The "sandbox" in its default configuration disabled various functions (such as os.remove) which could potentially cause a lot of havoc. This sandbox was designed so that individual plugins (and world files) could be "trusted" so that, if necessary, they could do things like open and write files.

  • The second problem was loading DLLs. A DLL (dynamic link library) by its very nature can execute anything at all (like, scanning all your directories, finding interesting files, and uploading them to some server). Thus the checkbox "Allow DLLs to be loaded" was introduced, so that if unchecked, no DLLs could be loaded. However if checked, then you still have the fallback of needing to trust the plugin.



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:


require "tprint"


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.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #1 on Thu 12 Aug 2010 12:50 AM (UTC)
Message
Nick Gammon said:
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.

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.

Nick Gammon said:
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.

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

Nick Gammon said:
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?".

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

Nick Gammon said:
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)


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


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


require "tprint"


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.

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.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by WillFa   USA  (525 posts)  [Biography] bio
Date Reply #2 on Thu 12 Aug 2010 02:24 AM (UTC)

Amended on Thu 12 Aug 2010 02:26 AM (UTC) by WillFa

Message
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...
Nick Gammon said:

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.

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.
[Go to top] top
Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #3 on Thu 12 Aug 2010 01:16 PM (UTC)
Message
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.
[Go to top] top
Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #4 on Thu 12 Aug 2010 01:29 PM (UTC)
Message
Just read the other topic, and quoting a post here to answer it to prevent pulling that topic further off-topic:

Nick Gammon said:

Worstje said:

The sandbox is a good idea, but in the end, the fact that MUSHclient supports other scriptiong languages that have no such feature means that in reality, it ends up with a serious usability gimp for your users.


Ah, I think I see the solution. De-implement support for the other languages. Then the sandbox does what it is designed to do - protect you.


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.
[Go to top] top
Posted by KaVir   Germany  (117 posts)  [Biography] bio
Date Reply #5 on Thu 12 Aug 2010 03:11 PM (UTC)

Amended on Thu 12 Aug 2010 03:12 PM (UTC) by KaVir

Message
Nick Gammon said:


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


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.

[Go to top] top
Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Reply #6 on Thu 12 Aug 2010 09:19 PM (UTC)
Message
KaVir said:

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.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Thu 12 Aug 2010 09:30 PM (UTC)
Message
Worstje said:

Lua is not suitable for every script out there.


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

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #8 on Thu 12 Aug 2010 09:37 PM (UTC)
Message
Nick Gammon said:
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.

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.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top
Posted by Twisol   USA  (2,257 posts)  [Biography] bio
Date Reply #9 on Thu 12 Aug 2010 11:12 PM (UTC)
Message
David Haley said:
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.

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

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Thu 12 Aug 2010 11:41 PM (UTC)
Message
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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Reply #11 on Thu 12 Aug 2010 11:44 PM (UTC)
Message
David Haley said:

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.


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.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Worstje   Netherlands  (899 posts)  [Biography] bio
Date Reply #12 on Fri 13 Aug 2010 12:12 AM (UTC)
Message
Nick Gammon said:

Worstje said:

Lua is not suitable for every script out there.


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


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?
[Go to top] top
Posted by Nick Gammon   Australia  (23,042 posts)  [Biography] bio   Forum Administrator
Date Reply #13 on Fri 13 Aug 2010 03:26 AM (UTC)
Message
You've got it, although I am starting to think all that effort isn't really worth it.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by David Haley   USA  (3,881 posts)  [Biography] bio
Date Reply #14 on Fri 13 Aug 2010 03:46 AM (UTC)
Message
Quote:
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.

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 Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

81,028 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

[Home]

Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]