[Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
noreply@sourceforge.net
noreply@sourceforge.net
Sun, 24 Mar 2002 13:41:57 -0800
Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole
Initial Comment:
The documentation of the restricted execution module,
rexec, should make it clear that it is dangerous to
allow the restricted code write into a directory that
is included in sys.path. Indeed, I suspect that is it
common to allow restricted code to write in the
current directory (e.g. after a chdir() to a directory
that contains only the files we want the restricted
code to work on). But '' is in sys.path by default.
Attached is a script that uses this to perform the
equivalent of an unmarshal of a code object (which is
forbidden in restricted mode -- although it is clear
to me why, it might not be obvious to someone not used
to Python's internals and should be mentionned
somewhere). The attached script writes and then import
a .pyc file that defines a function whose bogus code
(at least on 32-bit Unix machines with Python 2.2-2.3)
returns the frame of the caller. This lets the
restricted code access the original builtins.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 16:41
Message:
Logged In: YES
user_id=6380
Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.
Could I twist your arm and ask for a patch?
----------------------------------------------------------------------
Comment By: Armin Rigo (arigo)
Date: 2002-03-24 10:00
Message:
Logged In: YES
user_id=4771
This could be defeated by a double attack: one rexec'ed
code leaves a .pyc file in a temporary directory, and later
another rexec'ed code in a fully read-only environment
imports it. Or the buggy .pyc file was put there with some
other tool (e.g. ftp to /incoming).
To be on the safe side one could completely disable loading
from .pyc files. This has the advantage of automatically
fixing the problem in all of the existing applications. I
don't know if this would be a serious performance problem --
rexec'ed code might generally don't import too much
standard modules itself anyway. One could later add
a "safe_path" list that lists the directories from which
loading .pyc files is considered to be safe.
Note that the default hooks are such that no .pyc files are
ever *written* by imports from rexec'ed code. One can thus
guess that no existing rexec'ed code relies on .pyc file
performance for anything but the standard library.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53
Message:
Logged In: YES
user_id=6380
Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50
Message:
Logged In: YES
user_id=6380
Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects.
Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35
Message:
Logged In: YES
user_id=21627
Isn't that a bug in LOAD_FAST?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470