Page 2 of 2

Posted: Tue Jan 08, 2008 11:34 am
by Zeggy
I like what you're doing here, it sounds like it could be useful :)

The runkit sandbox sounds useful as well though, maybe you could try using that in your safer eval() function?

Re:

Posted: Sat Jan 12, 2008 3:04 am
by Weirdan
Mordred wrote: You're missing the point. I think you should not need user-scripting for a game (or an app). Noone but a handful of geeks would be able to use it. And some of them will be better at security than you (and me).
Mordred, it seems it's you who missing the point :) : most modern games need built-in scripting. The scripting usually is not intended to be used by gamers - instead it's used by modders to roll a variations of original game.

Re: The quest for safe eval() of user input

Posted: Sat Jan 12, 2008 5:07 am
by Kieran Huggins
sounds like what you need is a language with closures, which PHP isn't.

Or maybe an API? Let their code run in a separate process and interface with your app. That's how FB does it, and it seems to work.

Re: Re:

Posted: Sat Jan 12, 2008 5:36 am
by Mordred
Weirdan wrote:
Mordred wrote: You're missing the point. I think you should not need user-scripting for a game (or an app). Noone but a handful of geeks would be able to use it. And some of them will be better at security than you (and me).
Mordred, it seems it's you who missing the point :) : most modern games need built-in scripting. The scripting usually is not intended to be used by gamers - instead it's used by modders to roll a variations of original game.
I don't think so. Even if this could be applied to PC games (which isn't exactly true, but I won't go into this now; the burden of proof lies on you anyway), I don't see it applied to web games. There are popular games with lots of users and modding, but they are open-source and modding is done directly on the code base, or by writing plugins. There are also popular proprietary games, but no modding is done on them (at least none that I know of, which actually isn't much, so please provide a counter-example if you know of some such game)

Re: The quest for safe eval() of user input

Posted: Sat Jan 12, 2008 9:20 am
by feyd
I can verify that many (real) games use scripting languages to define a lot of behaviors rather than actual code. Unreal engine projects will usually use UnrealScript, which is based on ECMAScript, for example.

Either way, the idea of using eval() is hideous. It's far better to create a sandbox. Whether it's has to be PHP or simply interfaces with one's PHP is a choice one has to make, but I would suggest the latter approach by building an API and then code for a language or three to communicate with that API so that third-party developers aren't forced to use PHP.

Re: The quest for safe eval() of user input

Posted: Sat Jan 12, 2008 2:54 pm
by Mordred
feyd wrote:I can verify that many (real) games use scripting languages to define a lot of behaviors rather than actual code. Unreal engine projects will usually use UnrealScript, which is based on ECMAScript, for example.
Been there, done that, wrote the manual (literally).

Yes, scripting is a great way to separate engine code from game code and allow for quick modifications without recompile (or even, if one is wise enough, without restarting the executable). The key point is that this is done for the benefit of the developers, not for the sake of modders (bar a few games that did this on purpose, to invite modders). Or, it comes free with the 3rd party engine you're using.

But gamers would not care for it. They don't need a fancy script language, they need to enjoy the game.
Modders would not care for it either, not unless the game becomes hugely popular.
Modders would also suck at modding, because they generally don't have the resources, talent or experience to make an enjoyable mod.
In the end of the day you are left with only a handful of successfull mods ever made.

(Rant off, I know that was not exactly Weirdan's point) So yes, modern games use scripting. What does this have to do with web-based games? (Okay, we may say the same of web-based games, PHP *is* a scripting language after all ;) ) But do these two unrelated facts justify what Hory is trying to write on his grave, security-wise?

I don't think it pays to go through all the hassle to support modding for a web-based game.
I don't think gamers would appreciate it if the game allows user-level scripting either.
And I definitely don't think eval() is the way to do that, but we've already established that ;)

-----
@Kieran Huggins: closures? How would you use closures to provide a safe sandbox? You rather need a mechanism to limit the language's native API to a rich-yet-secure subset. This is trivial in some languages, and quite bordersome in others.

Re: Re:

Posted: Sat Jan 12, 2008 3:20 pm
by Weirdan
Mordred wrote: I don't think so. Even if this could be applied to PC games (which isn't exactly true, but I won't go into this now; the burden of proof lies on you anyway), I don't see it applied to web games.
On the second thought I would partially agree with you in that the scripting is used prevalently in PC games (I think it's dictated by the fact that most PC games are implemented in statically typed compiled languages like C, C++ and the like - an alternative would be a plugin architecture, but that would require writing a shared libraries - too much burden for a simple modder).
Mordred wrote: There are popular games with lots of users and modding, but they are open-source and modding is done directly on the code base
What an awful approach, don't you think?
Mordred wrote: , or by writing plugins.
That is much better, but sometimes it's desirable to additionally limit what plugins can do (on the language / stdlib level).That's the point of having sandboxes - and personally I don't see how a PHP sandbox (via runkit) is radically different from eval sandbox like Hory is trying to build.

Re: The quest for safe eval() of user input

Posted: Tue Jan 15, 2008 10:45 am
by Hory
First of all, sorry for not replying sooner, but it's only now that I've noticed this thread has a second page. :?

Regarding runkit - it's not a default PHP extension, right? That would it pretty much unusable on 99% of shared hosts.

As for why I need scripting in games - it's true that there are very few games in which the players need to do scripting themselves (e.g. combat "robot" programming games). In my case, I'm making a sort of RPG engine on which other developers could pre-script their stories and campaigns for players to play. So the third-party developers will definately need a way to script what goes on behind the curtains in their modules.

Building an API - yes, it might be a solution. It's just seems wrong to me, in a way, to put so much effort into it, only to have it do what PHP already does. That's why I'm trying it the other way around. I didn't want to make developers learn another "used only in one place" language either.

The only other thing I've found which seems adaptable without much effort is DORSL. But, as with most projects, development isn't active anymore, who knows what bugs or weaknesses it has, and even the documentation is so scarce that I haven't figured out how to use it yet. But I'm working on it :).

Re: The quest for safe eval() of user input

Posted: Tue Jan 15, 2008 11:01 am
by Kieran Huggins
Could you not run all user script inside a closure, passing in certain objects and limiting it's access to those? Maybe it depends on the language.

I'm probably full of <span style='color:blue' title='I&#39;m naughty, are you naughty?'>smurf</span>, but it seemed like a good idea at the time 8)

Re: The quest for safe eval() of user input

Posted: Tue Jan 15, 2008 2:36 pm
by Mordred
@Hory: You'll need to build a PHP API anyway - a set of allowed functions that the developers may call. There are many solutions to this without letting modders to write actual PHP code. Starcraft's level editor was entirely event based if I recall correctly, you might check how they did it. In fact, checking how other people solved the problem you're facing now is probably the first logical choice ;)

Anyway, you still need to address some more holes in your scripts.

@Kieran: A closure generally allows access to variables of a "parent" scope. It would not restrict access to variables of other scopes - for example the global one. From that point of view it is no different than just calling a function with a number of parameters. What Hory is trying to achieve, is to limit access to the rest of the variables (and also to some language constructs which is a double burden for him)

Re: The quest for safe eval() of user input

Posted: Wed Jan 23, 2008 11:51 pm
by dayyanb
Someone could create code that runs infinitely making your website vulnerable to a dos attack.

For example:

Code: Select all

while(1 == 1) {$i = 5/0;}

Re: The quest for safe eval() of user input

Posted: Thu Jan 24, 2008 12:48 am
by Mordred
dayyanb wrote:Someone could create code that runs infinitely making your website vulnerable to a dos attack.

For example:

Code: Select all

while(1 == 1) {$i = 5/0;}
\o/ Bravo! \o/

Somehow finding code execution flaws made me totally forget about DOS-ing, I'm ashamed. Well spotted, dayyanb. You've just turned Hory's safe eval quest into a quest of solving the halting problem, which is proven unsolvable --> :banghead:

Re: The quest for safe eval() of user input

Posted: Thu Jan 24, 2008 1:20 am
by Kieran Huggins
Mordred wrote:A closure generally allows access to variables of a "parent" scope. It would not restrict access to variables of other scopes - for example the global one. From that point of view it is no different than just calling a function with a number of parameters. What Hory is trying to achieve, is to limit access to the rest of the variables (and also to some language constructs which is a double burden for him)
Indeed you are correct - closures isolate their own variable scope, but don't limit access to globals. But they don't allow access to the parent scope, do they? My understanding is that you have to pass in anything that you want to access. At least this is what seems to be the case in ECMA Script & Ruby...

Regardless, your point about malicious code is spot on. Closures are certainly not a solution here.

Re: The quest for safe eval() of user input

Posted: Thu Jan 24, 2008 4:14 am
by Hory
I was aware about the infinitely looping code, but really, isn't this a problem that any interpreter is susceptible to? Even the most limited of scripting languages can be sent into such a loop. Limiting script execution time might be an option, but, of course, it would still suck resources for some seconds...

Re: The quest for safe eval() of user input

Posted: Thu Jan 24, 2008 4:59 am
by Mordred
Kieran Huggins wrote:But they don't allow access to the parent scope, do they?
On the contrary, this is exactly what closures are - a function, that accesses the local variables of the parent scope as if they were globals. If you pass them what they need to access, then it's just regular functions ;)

Hory, you still haven't fixed the damned code. And your web site code is vulnerable to multiple XSS and mail header injection.