View Full Version : Lua sandbox

01-10-2007, 05:49 AM
It might be prudent to disable part of the Lua standard library. (Although it's probably not that big of a concern.)

I think the easiest way to do it is just to set the offending packages/methods to nil in the Novashell/system scripts. Sure, someone can edit them, but that only effects their own system. There's probably another way to do this in C though. As far as I can tell, the only packages that warrant concern are io and os. os.execute("rm *") :)

The os package contains all the scary stuff like os.execute. Unless people want to be able to know what the current time and date is, the whole package can be set to nil. Otherwise, os.remove, os.rename, and os.execute should be. os.setlocale should probably be too as changing the locale is asking for trouble. os.exit might bypass clean-up code, and os.tmpname is useless if file IO is disabled.

01-11-2007, 09:52 AM
Yikes, these were supposed to be disabled already, thanks very much for bringing this to my attention.

I've put up a new windows build with io removed, and the dangerous pieces of os clipped as well. (I figured the date and time stuff might be useful)

Note: These are removed at the C++ level, there is a serious weakness in counting on the base system scripts to do it - anything and everything from that directory can be overriden if it exists in the world you're playing, including system/startup.lua!

My goal is you should never be afraid of running a world you downloaded somewhere, so please let me know if you think of any other security problems.

01-12-2007, 05:37 AM
I missed something from the library.

require() and package.loadlib() can load c libraries. So I guess the whole package subsystem can go if it hasn't been removed already. (Though I actually devised a use for package.cpath. Useless now without io though. :() Those gone, that leaves loadfile() and dofile(). RunScript() probably supersedes those. I think that's basically everything for the standard library. If you care about users messing with the garbage collection, then you might want to hide collectgarbage() as well.

I think trying to make anything more secure after that is impossible. Someone could discover some buffer overflow and then exploit it, but I seriously doubt anyone would take the time. I did, however, find one by accident and posted it on the bug message board. A user could also manage to allocate a ton of memory or loop infinitely but these are little more than annoyances.

01-17-2007, 06:10 AM
Thanks, removed.