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/archive%40mail-archive.com
