Bug#493937: Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd

[James Vega]

On Wed, Aug 06, 2008 at 01:39:15AM +0100, Simon McVittie wrote:
> Shouldn't Python builds of vim avoid this bug by stopping '' from being
> prepended to sys.path in the first place?

As I mentioned earlier[0][1] in the bug log, I don't think removing ''
from sys.argv is the correct change to make in Vim.

> After looking through Python initialization and vim's if_python.c it
> seems that the way forward is to set Python's argv, via PySys_SetArgv(),
> to have a non-empty and absolute first argument.
> 
> vim sets Python's argv to  { "", NULL }, which according to a comment is to
> avoid a crash when warn() is called. Changing that to { "/usr/bin/vim", NULL }
> would seem to solve this problem - but for that matter, any safe value is fine.

The way Vim is using PySys_SetArgv (and therefore the resulting
behavior) is exactly following the recommended use of PySys_SetArgv
according to upstream's documentation[2].

> A safe value for argv[0] is any value where there won't be files dir/*.py or
> dir/*/__init__.py, where dir == dirname(argv[0]). So setting argv[0] to
> "/", "/usr/lib/something" or "/usr/share/vim" would be safe too, for instance.
> 
> I'm afraid I haven't tested this in vim itself (the multiple builds take a
> while...) but the attached program demonstrates it:
> 
> smcv at carbon% gcc -o484305 `python-config --cflags` `python-config --ldflags` 484305.c
> smcv at carbon% ./484305
> (I have no argv!)
> ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']
> smcv at carbon% ./484305 ""
> ['']
> ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']
> smcv at carbon% ./484305 "/usr/bin/vim"
> ['/usr/bin/vim']
> ['/usr/bin', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']

While this does provide a workaround for the issue, this is behavior
inherent in the way Python is designed and should be fixed in Python.
If we choose to instead address every application that embeds Python,
we're just creating an endless stream of work for ourselves.

From a quick check via Google's codesearch, at least X-Chat[3],
Gnumeric[4], python-nautilus[5], and gedit[6] are likely to have this
same problem.

N.B., most of the above projects use a single-element argv of the
project name.  This is no different than using a single-element argv of
"" since PySys_SetArgv attempts to resolve argv[0] to an absolute path
and uses "" when it is unable to do so.

[0] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#51
[1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#61
[2] - "If there isn't a script that will be run, the first entry in argv
      can be an empty string."
      http://docs.python.org/api/initialization.html#l2h-881
[3] - http://ln-s.net/27az
[4] - http://ln-s.net/27ay
[5] - http://ln-s.net/27b1
[6] - http://ln-s.net/27b9
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20080805/9036c2aa/attachment-0001.pgp