CVE-2008-5983 "untrusted python modules search path"

Hello,
I don't think it has already posted to the list, apologies if it has.
Some Linux tools and vendors have been hit by an alleged "security hole" where an embedded Python interpreter will prepend the current working directory to sys.path as soon as PySys_SetArgv() is called by the embedding application. This means, for example, that a Python file in the working directory can break plugins or extensions written for that application if the Python file happens to shadow another module.
Regardless of whether this is a security hole or not, it certainly can make things disturbingly surprising when the situation arises. In the bug report (http://bugs.python.org/issue5753), I suggested we add a new function PySys_SetArgvEx() which would take an additional parameter telling whether to touch sys.path or not (in the same spirit as Py_InitializeEx() providing a more flexible API than Py_Initialize()).
On the other hand, I don't think we can change the default behaviour of PySys_SetArgv(), since there are probably tools and applications relying on it (the obvious use case which comes to my mind is a third-party interactive interpreter).
Any opinions?
Regards
Antoine.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Antoine Pitrou napsal(a):
Hello,
I don't think it has already posted to the list, apologies if it has.
Some Linux tools and vendors have been hit by an alleged "security hole" where an embedded Python interpreter will prepend the current working directory to sys.path as soon as PySys_SetArgv() is called by the embedding application. This means, for example, that a Python file in the working directory can break plugins or extensions written for that application if the Python file happens to shadow another module.
Regardless of whether this is a security hole or not, it certainly can make things disturbingly surprising when the situation arises. In the bug report (http://bugs.python.org/issue5753), I suggested we add a new function PySys_SetArgvEx() which would take an additional parameter telling whether to touch sys.path or not (in the same spirit as Py_InitializeEx() providing a more flexible API than Py_Initialize()).
On the other hand, I don't think we can change the default behaviour of PySys_SetArgv(), since there are probably tools and applications relying on it (the obvious use case which comes to my mind is a third-party interactive interpreter).
Any opinions?
yes! Actually, i wanted to propose and implement something like this back when this vulnerability appeared, but i never got to it.
I'd propose to create a whole new function, called, say, PySys_FillArgv() (no, i don't think that's a very good name) that would - -only- fill sys.argv and not touch sys.path. In addition to that, there would be a function like PySys_SetScriptPath() that would not fill sys.argv, but prepend the script's directory to sys.path Then i'd reimplement PySys_SetArgv as { PySys_FillArgv(); PySys_SetScriptPath(); }
And as a final killing step, i would never ever mention PySys_SetArgv anywhere but in its own documentation ;e) And especially not in the first page of "Embedding Python".
My rationale is that the only application deliberately using PySys_SetArgv the way it's written is a Python interpreter. For that, it's desirable to have '.' in sys.path _when no script is being executed_. For *all other applications*, this makes no sense ;e)
regards m.
Regards
Antoine.
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/jmatejek%40suse.cz
participants (2)
-
Antoine Pitrou
-
Jan Mate(jek