Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, 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.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ MUSHclient
➜ General
➜ 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 page
Pages: 1
2
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #15 on Fri 13 Aug 2010 04:58 AM (UTC) |
| Message
| 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. | | Top |
|
| Posted by
| WillFa
USA (525 posts) Bio
|
| Date
| Reply #16 on Fri 13 Aug 2010 12:35 PM (UTC) |
| Message
| 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? | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #17 on Fri 13 Aug 2010 02:20 PM (UTC) |
| Message
|
Worstje said:
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.
Ah... you might have missed this somewhat important and perhaps relevant sentence :-)
I said:
(and there's no reason why things it loads wouldn't be subject to the same security mechanism)
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 Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #18 on Fri 13 Aug 2010 04:08 PM (UTC) |
| Message
| 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. :) | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #19 on Fri 13 Aug 2010 05:01 PM (UTC) |
| Message
|
Quote:
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.
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. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #20 on Fri 13 Aug 2010 09:28 PM (UTC) |
| Message
| 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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #21 on Fri 13 Aug 2010 09:31 PM (UTC) |
| Message
|
WillFa said:
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?
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. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Twisol
USA (2,257 posts) Bio
|
| Date
| Reply #22 on Fri 13 Aug 2010 10:15 PM (UTC) |
| Message
|
Nick Gammon said:
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.
This sounds great to me!
Nick Gammon said:
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.
I completely agree. Security has to be considered from the absolute beginning. |
'Soludra' on Achaea
Blog: http://jonathan.com/
GitHub: http://github.com/Twisol | | Top |
|
| Posted by
| Worstje
Netherlands (899 posts) Bio
|
| Date
| Reply #23 on Sat 14 Aug 2010 02:50 AM (UTC) |
| Message
| | Nick basically affirmed what I suggested in my final post, so yeah, I'm in full favor of such changes myself. Usability ftw! :) | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #24 on Sat 14 Aug 2010 03:40 AM (UTC) |
| Message
| OK changed to make the non-intrusive sandbox the default in version 4.57.
Note that existing sandboxes will not be affected. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #25 on Sat 14 Aug 2010 10:15 PM (UTC) Amended on Sun 15 Aug 2010 12:27 AM (UTC) by Nick Gammon
|
| Message
|
That describes how to disable existing sandboxes.
That post is also available through the shortcut link:
http://www.gammon.com.au/security
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #26 on Sat 14 Aug 2010 10:19 PM (UTC) |
| Message
|
Quote:
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.
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.) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #27 on Sat 14 Aug 2010 10:39 PM (UTC) |
| Message
| 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".
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #28 on Sat 14 Aug 2010 10:44 PM (UTC) |
| Message
| 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.
Quote:
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".
Yes, I don't think the social problem can ever really be solved technically. This is the bane of all computer security problems, really. :-( |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,165 posts) Bio
Forum Administrator |
| Date
| Reply #29 on Sat 14 Aug 2010 10:59 PM (UTC) Amended on Sun 15 Aug 2010 12:27 AM (UTC) by Nick Gammon
|
| Message
| 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". |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | 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.
104,989 views.
This is page 2, subject is 2 pages long: ![[Previous page]](/images/thin_prev.gif)
1
2
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top
