Sign in to follow this  
Storyyeller

scripting security issues

Recommended Posts

When people write games, how do they ensure that the scripting does not allow malicious behavior in user created levels? One option I've seen is to create a very limited language and custom interperter, but that has the problem of reinventing the wheel as well as allowing less freedom.And even this option is not completely foolproof, as Blizzard discovered with WC3.

Share this post


Link to post
Share on other sites
[quote name='Storyyeller' timestamp='1302979174' post='4799208']
When people write games, how do they ensure that the scripting does not allow malicious behavior in user created levels? One option I've seen is to create a very limited language and custom interperter, but that has the problem of reinventing the wheel as well as allowing less freedom.And even this option is not completely foolproof, as Blizzard discovered with WC3.
[/quote]
Well, Lua (and probably other languages) only have the functions accessible that you make accessible. So only allow the functions that you want to user to be able to access. In Lua, you can even have multiple different such sandboxes, with different functions available in each one.

In my game, I'll eventually have a couple different Lua sandboxes for different purposes. One for loading the world, loading graphics, etc... One for enemy AI, one for player and enemy skills and attacks, one for NPC dialog, and one for events that the player activates while traveling (this will probably be mixed with the NPC dialog one, in a single sandbox since they interrelate).

Just like C++, where C++ only lets you access the functions that's available in your 'scope' and it's considered bad to have variables in the 'global' scope, it's the same with scripting languages (though the language may call it something else, and you may use it in a different way). The way I'm currently using Lua, I make each Lua sandbox (called a lua_state) only have the functions that the scripts being ran by that state needs access to, and maybe a few extra for convenience.
Sure, Lua has plenty of libraries that add functions like "Delete folder on the user's computer", but it's the programmer's choice which of those libraries he actually wants to add, and to which sandbox he wants to add them.
Also, since you get to write your own functions if you want, you can even write your own DeleteFolder() function in C++ and add it to your Lua-usable functions, and in your function, check to make sure that the path put in is limited only to areas and folders that you want the user to be able to delete.

You only really have problems, when you just tell your scripting language "Make every function available" without thinking. Don't just add every function or every library - choose which ones you actually need, and then only add those. And if 19 of the functions in the library are perfectly safe, but 1 function isn't, then add the entire library to the sandbox, and then explicitly remove the dangerous function (in Lua you can do this by defining that function as nil).

Share this post


Link to post
Share on other sites
If the script is ever able to look outside the game itself (e.g. it can read files or access the network), then make sure you impose a limit on such functionality. For example, if a script is allowed to read a file, make sure the script can only read files from within a given directory (this is also why some libraries like PhysFS ignore symbolic links by default).

Share this post


Link to post
Share on other sites
Blizzard's usage of Lua isn't quite perfect, there are still some strange edge cases like changing a frame's parent inside it's 'OnShow' event handler, particularly when that event was itself cause by changing a frames parent from a hidden frame to a visible frame.

Still, Blizzard definitely did some things right, such as refusing to run unsigned Lua code until after the has entered the game - probably a huge step toward preventing account theft.

AddOns are also completely denied access to the hosts filesystem. If an AddOn wants to save and load data, it has do declare one ore more global variables to put it in and the game will save it when the player logs out and restore it when the AddOn is loaded again.

Share this post


Link to post
Share on other sites
Some other things that you should be aware of are things like infinite loops in scripts, or scripts with runaway memory allocation (which can potentially crash the process.) These don't have as much potential to do malicious things to the host system but can still ruin the experience. Also, if you're allowing user scripts on a server, these types of things could easily take down the server without violating the 'sandbox' per se.

Share this post


Link to post
Share on other sites
[quote name='SHilbert' timestamp='1305692258' post='4812247']
Some other things that you should be aware of are things like infinite loops in scripts, or scripts with runaway memory allocation (which can potentially crash the process.) These don't have as much potential to do malicious things to the host system but can still ruin the experience. Also, if you're allowing user scripts on a server, these types of things could easily take down the server without violating the 'sandbox' per se.
[/quote]

That reminds me of Warcraft 3. Some maps deliberately caused crashes as part of a player kicking or anti hacking mechanism.

Share this post


Link to post
Share on other sites
[url="http://en.wikipedia.org/wiki/Buffer_overflow"]Buffer overruns[/url] are something you'll always wanna avoid letting happen.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this