Security and Distribution

[RedEyeCoder]

(this is not directly an Ogre question, however the application in question uses Ogre.)

Hi all, I have some security questions relating to distributing software with an embedded scripting language, in my case python and lua. My question can be summed up as the following, is it a realistic concern that people may "piggy back" your (trusted) application to execute malicious script? And if so, what realistic measures can be taken to prevent or handle this.

I know lots of games which have embedded python/lua and I wonder how/if they approached this problem. I have read a bunch of "guides" and papers about securing python, but none of them seem very approachable with my limited knowledge of python, and I have not even begun to read about sandboxing lua.

[reptor]

Well, I have been thinking about this as well.

I integrated Lua into my game.

First thing that came into my mind about it was to take out components from Lua which make it possible to do file input/output in the filesystem, outside the application's directories. What I am planning to do is to allow the user to use Lua to read files only from a certain place. I am thinking that I could allow reads from a profile directory which is located in the user's home directory. That would be where the user would place his or her custom scripts. Then I would of course allow the game to read its own original script files from its installation directory. For the original script files I am thinking of writing a system which checks that the files are really the original ones and not modified files (that will become important if the game has a multiplayer mode, each client is only supposed to be running only original files no matter is the "server is authoritative" model used or not, that model, as I see it, cannot be used for everything so cheaters would have likely many possibilities to cheat by writing custom scripts if you don't verify that the files are original).

Then the writing part must be considered separately; do you even want to allow writing to file at all? I know that many games which have an integrated scripting language do not have any way to write to files (people can create hacks around that, though, by writing their own little program which somehow interferes with how your application works, but we can't stop that).

So I think Lua in its standard full form needs to have some parts stripped out or strictly controlled if you want to prevent bad things from happening. At least you should be controlling what locations the scripts can read & write I think. And consider if you want to allow user scripts writing to filesystem at all. If you exclude it completely then it excludes quite a lot of danger. My approach to this, as I already said, is to restrict scripts reading (and maybe writing if I decide to allow it) to only a certain subdirectory of the application's profile directory in the current user's home directory and the application's installation directory (maybe I will explicitly control which files can be read from the application's installation directory, this requires file signature checking). I haven't written it yet but I plan to do it.

[RedEyeCoder]

I am surprised at the lack of response to this. Is this not a good place to talk about it? I thought more people in the community would have more to say, especially since the issue involves distribution.

If someone knows of a more appropriate place, please point me in the right direction

[darke]

When the second post in the thread covers everything most people will think of, there's little reason to waste time and energy to add "me too"?

Or maybe no one sees it as a significant risk in their application to work around it?

Consider:
* If you're not allowing offical modding (or not exposing the api to non-developers), or just not expecting people to mod it (point and click adventure games and the like), there's no real reason.

* If you're allowing modding and you're big enough to be targeted (aka, WoW, Halflife and the like), then the main vector for "ungood" programs will be the .msi/exe installer people would social engineer them to download to easily install the mod. That way they can get a stock keygrabber/trojan/whatever and plonk it on your machine without any real effort on their part. They don't need any specialist knowledge of your application. (That's not to say you don't do the simple low hanging fruit stuff.)

And the obvious simple solution:
* Doing a quick wrapper around the various I/O routines (open/mkdir/chdir/etc) to do a regexp to reduce ".." to "." or "", and prepend a prefix to all filenames.

In the end the answer you want is really sensitive to the threats you're defending against. "Piggy backing your trusted application to do something malicious" could mean anything. Are you defending against transparent-wall-hacks? Stopping people from installing key loggers? Exploting your game through race conditions or buffer overruns? Placing a surreptitious order to an online pizza place to get a pizza delivered to the gamer's house? (... actually, that'd be a neat trick to try.)

WoW's threat model will be different from HL2 Deathmatch's threat model. Which will be different from Adventure Game Of The Year's threat model. Which will be different from Derivative Console FPS's threat model. Which will be different from Random Sports Game 200X's threat model.

In short, (which I should have done at the top and stopped rather then rambled ) if you can enumerate what you're defending against, it will be more clear as to what you need to do to defend it, or if you actually need to defend at all.

[faraklit]

we tried encrypting python scripts and load scripts dynamically inside c++
but still the pyd files signatures' are exposed.