Is this a security risk with Python too?
rnd at onego.ru
Fri Aug 16 19:39:33 CEST 2002
On 16 Aug 2002, Bernhard Herzog wrote:
>Gerhard HДring <gerhard.haering at opus-gmbh.net> writes:
>> Roman Suzi wrote:
>> > Among numerous security alerts, I saw the following:
>[current working directory on a module search path]
>> > Is this true for Python too (in some cases)?
>> No, unless you explicitely put the working directory into Python's search
>> path by changing PYTHONPATH or sys.path, for example.
>Or when you're running in interactive mode or the script you pass on the
>commandline is in the working directory.
Still I think it's more serious. Look at this:
$ echo '0/0' > re.py
Python 2.2.1 (#1, May 21 2002, 09:12:04)
>>> import re
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'compile'
The problem is, by default, modules in the local directory have priority over
standard libraries. So, if the author of Python virus will call it as one of
the standard modules and tricks me into even simply _saving_ his file into
$HOME, Trojan could trigger by any innocent program I will try in the same
And do I need to know every Python module in order to safely name a program
and safely run it from some directory? The same is true for *.so files.
Maybe it is feasible to have two pythons: one which seeks curdir last (or not
at all) (spython) and another - the usual one. This way system utilities could
use Python scripts with better safety, even if they are copied to the current
Consider, for example, cp.py program which could copy files by making use of
shutil module. Now, for some reason, I copy it into this dir, which has lots
of modules! Sadly, shutil.py is among them and the cp.py utility doesn't work.
I think, my idea is not completely outlandish.
Sincerely yours, Roman Suzi
rnd at onego.ru =\= My AI powered by Linux RedHat 7.2
aaro at onego.ru <- not to be mailed to
More information about the Python-list