开发者

What builtin functions shouldn't be run by untrusted users?

开发者 https://www.devze.com 2023-01-24 16:55 出处:网络
I\'m creating a corewars type application that runs on django and allows a user to upload some python code that will control their character.Now, I know the real answer to this is that as long as I\'m

I'm creating a corewars type application that runs on django and allows a user to upload some python code that will control their character. Now, I know the real answer to this is that as long as I'm taking code input from untrus开发者_StackOverflowted users I'll have security vulnerabilities. I'm just trying to minimize the risk as much as possible. Here are some that spring to mind:

  • __import__ (I'll probably also do some ast scanning to make sure there aren't any import statements)
  • open
  • file
  • input
  • raw_input

Are there any others I'm missing?


There are lots of answers on what to do in general about restricting Python at http://wiki.python.org/moin/SandboxedPython. When I looked at it some time ago, the Zope RestrictedPython looked the best solution, working with a whitelist system. You'll still need to take care in your own code so that you don't expose any security vulnerabilities, but that seems to be the best system out there.


Since you sound determined to do this, I'll link you to the standard rexec module, not because I think you should use it (don't - it has known vulnerabilities), but because it might be a good starting point for getting your webserver compromised your own restricted-execution framework.

In particular, under the heading "Defining restricted environments" several modules and functions are listed that were considered reasonably safe by the rexec designer; these might be usable as an initial whitelist of sorts. I'd also suggest examining its code for other gotchas you might not have thought of.


You will really need to avoid eval. Imagine code such as:

eval("__impor" + "t__('whatever').destroy_your_server")

This is probably the most important one.


Yeah, you have to whitelist. There are so many ways to hide the bad commands.

This is NOT the worst case scenario:

the worst case scenario is that someone gets into the database

The worst case scenario is getting the entire machine rooted and you not noticing as it probes your other machines and keylogs your passwords. Isolate this machine and consider it hostile (DMZ, block it from being able to launch attacks internally and externally, etc). Run tripwire or AIDE on non-writeable media and log everything to a second host.

Finally, as plash shows, there are a lot of dangerous system calls that need to be protected against.


If you're not committed to using Python as the language inside the game, one possibility would be to embed Lua using LunaticPython (I suggest the bugfixes branch at https://code.launchpad.net/~dne/lunatic-python/bugfixes).

It's much easier to sandbox Lua than Python, and it's much easier to embed Lua than to create your own programming language.


You should use a whitelist, rather than a blacklist. If you use a blacklist, you will always miss something. Even if you don't, Python will add a function to the standard library, and you won't update your blacklist in time.

Things you're currently allowing but probably should not include:

  • compile
  • eval
  • reload (if they do access the filesystem somehow, this is basically import)

I agree that this would be very tricky to do correctly. One complication (among many) could be a user accessing one of these functions through a field in another class.

I would consider using another isolation mechanism, such as a virtual machine, instead or in addition to this. You might look at how codepad does it.

0

精彩评论

暂无评论...
验证码 换一张
取 消