5 ms·

As far as I know, Zope's sandbox has not been broken: https://pypi.python.org/pypi/RestrictedPython https://pypi.python.org/pypi/RestrictedPython The approach

by Erwin 12y ago

As far as I know, Zope's sandbox has not been broken: https://pypi.python.org/pypi/RestrictedPython https://pypi.python.org/pypi/RestrictedPython The approach there is to rewrite your Python code to disallow any potentially bad operation. E.g. your code cannot access identifiers starting with _ and the list of builtins is restricted (no "open" by default obviously, but also no "type"!) Any sandbox code doing X.Y is rewritten to _your_getattr(X, "Y") which can decide whether to allow access or not at runtime. The main thing to be careful of, is not accidentally injecting any callables like "file" into there, as just calling an object does not undergo a security check (given that you might want to pass some data INTO your sandbox). This does not limit resource usage however, i.e. you can still try to allocate memory/use up CPU time.

JohnnyGrey 12y ago
That's exactly what I though, the python code need to be alternated to get the returning approach. Thanks for pointing that out!
nl 12y ago
Note that the documentation contains the following: "RestrictedPython was bad idea and mostly causes headache. Avoid through-the-web Zope scripts if possible."[1] [1]http://docs.plone.org/develop/plone/security/sandboxing.html http://docs.plone.org/develop/plone/security/sandboxing.html
dalke 12y ago
Quoting from the bug page for "Zope sandbox escape via SecureModuleImporter from Products/PageTemplates/ZRPythonExpr.py" at https://bugs.launchpad.net/zope2/+bug/1047318 https://bugs.launchpad.net/zope2/+bug/1047318 : > Restricted code doesn't actually protect against malicious users. It's only a best-effort attempt against introducing accidental security issues for semi-professional developers. BTW, another attack vector (besides resource use) is to use code that causes Python itself to crash. For example, "{[{}]}".format({"{}": 5}) will segfault Python 3.3 (see http://bugs.python.org/issue17644 http://bugs.python.org/issue17644 ). The harder question is, are any of the ways to segfault Python exploitable?

by Erwin 12y ago

JohnnyGrey 12y ago

That's exactly what I though, the python code need to be alternated to get the returning approach. Thanks for pointing that out!

nl 12y ago

Note that the documentation contains the following: "RestrictedPython was bad idea and mostly causes headache. Avoid through-the-web Zope scripts if possible."[1] [1]http://docs.plone.org/develop/plone/security/sandboxing.html http://docs.plone.org/develop/plone/security/sandboxing.html

dalke 12y ago

Quoting from the bug page for "Zope sandbox escape via SecureModuleImporter from Products/PageTemplates/ZRPythonExpr.py" at https://bugs.launchpad.net/zope2/+bug/1047318 https://bugs.launchpad.net/zope2/+bug/1047318 : > Restricted code doesn't actually protect against malicious users. It's only a best-effort attempt against introducing accidental security issues for semi-professional developers. BTW, another attack vector (besides resource use) is to use code that causes Python itself to crash. For example, "{[{}]}".format({"{}": 5}) will segfault Python 3.3 (see http://bugs.python.org/issue17644 http://bugs.python.org/issue17644 ). The harder question is, are any of the ways to segfault Python exploitable?