Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Bugs

[issue5753] CVE-2008-5983 python: untrusted python modules search path

 

 

Python bugs RSS feed   Index | Next | Previous | View Threaded


report at bugs

Jul 9, 2009, 7:00 AM

Post #1 of 9 (329 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path

Jan Lieskovsky <iankko [at] seznam> added the comment:

Hello guys,

what's the current state of this issue? The proposed patch hasn't
still been projected into upstream Python code, so wondering:
1, when and if it will be?
2, if you have found another solution / patch?

Thanks && Regards, Jan.
--
Jan iankko Lieskovsky

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 9, 2009, 7:07 AM

Post #2 of 9 (305 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

Hello,

> what's the current state of this issue? The proposed patch hasn't
> still been projected into upstream Python code, so wondering:
> 1, when and if it will be?

I was hoping for more feedback before committing it. While it has been
labeled a security issue, not many people seem to actually care. Distro
maintainers doing their own patching without communicating with us
doesn't help either.

> 2, if you have found another solution / patch?

If it were so this bug would have been closed.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 9, 2009, 10:39 AM

Post #3 of 9 (309 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Tomas Hoger <thoger [at] redhat> added the comment:

Have you considered something like this? (patch against 3.1)

--- Python/sysmodule.c.orig
+++ Python/sysmodule.c
@@ -1643,6 +1643,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
#endif /* Unix */
}
#endif /* All others */
+ if (n > 0 || argv0 == NULL || wcscmp(argv0, L"-c") == 0) {
a = PyUnicode_FromWideChar(argv0, n);
if (a == NULL)
Py_FatalError("no mem for sys.path insertion");
@@ -1650,6 +1651,7 @@ PySys_SetArgv(int argc, wchar_t **argv)
Py_FatalError("sys.path.insert(0) failed");
Py_DECREF(a);
+ }
}
Py_DECREF(av);
}

I presume main problem here is that '' may end up as first item in
sys.path in certain cases.

That is desired in some cases, namely:
- python run in interactive mode
- python -c '...'

It does not happen and is not desired in other cases:
- ./foo.py
- python foo.py
- env python foo.py

Here foo.py can be just filename or filename with relative or absolute
path. In all these cases python seems to set argv0 to something
realpath can resolve.

Problematic case is embedded use when bogus argv0 can cause '' to be
added to sys.path, but it's usually not desired / expected (is anyone
aware of the case when that is expected?). It can be argued whether
apps should use garbage as argv0, but example in Demo/embed/demo.c do it
as well...

Patch above attempts to skip modification of sys.path when realpath
failed (n == 0). There are two special cases, that are treated as
special on couple of other places in PySys_SetArgv already:
- argv0 == NULL (interactive python)
- argv0 == "-c" (python -c)

This should fix the problem for apps embedding python and providing
garbage argv0. It would not make a difference for apps that provide
some valid path as argv0. I'm not aware of non-embedded python use that
will end up with different sys.path after this patch.

Ideas? Anyone is aware of the valid usecase that can break with this?

Advantage to Ex approach is that it does not require change on the
embedding apps side, and should really impact only those setting garbage
argv0.

----------
nosy: +thoger

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 12, 2009, 8:43 AM

Post #4 of 9 (297 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

Tomas, your patch is breaking an existing API, which may break existing
uses (I'm not sure which ones, but people are doing lots of things with
Python). That's why I proposed a separate API, which has the additional
benefit of making things clearer rather than muddier.

Besides, parsing of command line flags is already done in
Modules/main.c, we shouldn't repeat it in sysmodule.c.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 13, 2009, 3:26 AM

Post #5 of 9 (296 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Tomas Hoger <thoger [at] redhat> added the comment:

Additional API has one disadvantage - it requires a modification of all
affected applications embedding python, which is not likely to happen
soon after the API is introduced.

Therefore, it may still be worth reviewing current behaviour (that
seemed to have had no documentation until recently, see issue #5144, and
can probably still benefit from more warnings related to the embedded
use) in this corner case (argv0 is bogus and contains no '/') to see if
it may be worth changing in future python versions.

As for command line flags, I presume you're referring to the
'wcscmp(argv0, L"-c")' part of the patch. It's not more than a re-use
of the pattern already used couple of times in the PySys_SetArgv, that
got added via:

http://svn.python.org/view?view=rev&revision=39544

Again, it's an attempt to make sure this only changes behaviour in
rather specific case.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 13, 2009, 6:01 AM

Post #6 of 9 (297 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

Indeed, it would certainly be useful to review current behaviour and
document it precisely; and then, perhaps change it in order to fix the
current bug. The problem is that the current behaviour seems to have
evolved quite organically, and it's not obvious who relies on what (as I
said, Python has many users). I'm not myself motivated in doing such a
research. Perhaps other developers can chime in.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 13, 2009, 6:14 AM

Post #7 of 9 (297 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

Besides, the new API makes the behaviour more explicit and puts the
decision in the hands of the embedding developer (which certainly knows
better than us what he wants to do).
As the Python Zen says:

In the face of ambiguity, refuse the temptation to guess.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 15, 2009, 1:54 PM

Post #8 of 9 (285 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Jan Lieskovsky <iankko [at] seznam> added the comment:

Link to older Python tracker issue discussing the same problem and
closed with "won't fix":

http://bugs.python.org/issue946373

Strange enough, but implied from reading above issue, just an
idea (don't shoot :)). Wouldn't it be possible to recognize,
if the module name the script | embedded application is trying
to load belongs to && conflicts with the 'standard' Python module
names as listed in:

http://docs.python.org/modindex.html

and in that case:
a, issue a warning by loading it?
b, refuse to import it, in case it doesn't come from usual
standard Python modules location?

Probably off-topic, but is there in Python some mechanism how to
determine, if the module / module name belongs to:
a, 'standard Python module set' or
b, is a custom module, written by Python user?
(via the Python's interpreter __main__ module's namespace
dictionary? -- based on [1])

[1] http://www.linuxjournal.com/article/8497

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Jul 16, 2009, 12:03 AM

Post #9 of 9 (269 views)
Permalink
[issue5753] CVE-2008-5983 python: untrusted python modules search path [In reply to]

Tomas Hoger <thoger [at] redhat> added the comment:

This is not really the same thing as issue 946373. That one seems to be
about adding script's directory as the first thing in sys.path.
Comments there seem to mix both interactive ('' in sys.path) and
non-interactive (os.path.dirname(os.path.abspath(sys.argv[0])) in
sys.path) python uses, while CVE-2008-5983 is only about '' in sys.path,
mostly related to embedded use, rather than for python interpreter itself.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue5753>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Python bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.