Is this a security risk with Python too?

[Roman Suzi]

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
$ python2
Python 2.2.1 (#1, May 21 2002, 09:12:04)
>>> import re
>>> re.compile("123")
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
directory!

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
dir.

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