None of those are useful attacks on app engine though. On Mon, Feb 23, 2009 at 7:57 AM, Victor Stinner <victor.stinner@haypocalc.com> wrote:
Le Sunday 22 February 2009 17:45:27 Guido van Rossum, vous avez écrit :
I've received some enthusiastic emails from someone who wants to revive restricted mode. (...) Based on his code (the file secure.py is all you need, included in secure.tar.gz) it seems he believes the only security leaks are __subclasses__, gi_frame and gi_code. (I have since convinced him that if we add "restricted" guards to these attributes, he doesn't need the functions added to sys.)
Some ways to "crash" Python:
- use ctypes: invalid memory read/write - use os.kill(): kill the current process - call buggy function: invalid memory read/write or denial of service - "while 1: pass": denial of service - allocate many huge objects: MemoryError (maybe invalid memory read/write) - load a buggy .pyc file: invalid memory read/write - recursive structures/function calls: stack overflow (in buggy functions, see the bug tracker) - etc.
Protections against these attacks:
- Module whitelist (or a least use a blacklist of all modules written in C) - use system quota: resource.setrlimit() on Linux => set max CPU time and max memory limits (or signal.alarm() for the timeout) - Run a fuzzer on Python and fix all bugs :-)
I wrote a short document in Python's wiki on the different security projects:
http://wiki.python.org/moin/Security
-- Victor Stinner aka haypo http://www.haypocalc.com/blog/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)