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

Jesús Cea Avión added the comment: This issue is equivalent to MS Windows DLL hijacking (the MS situation is worse, because the DDL can be in network shares or, even , in remote webdav servers): http://blog.metasploit.com/2010/08/exploiting-dll-hijacking-flaws.html http://news.cnet.com/8301-2

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

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

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

A.M. Kuchling added the comment: Since the function was also added to 2.6, the 2.6 What's New should mention it; added in rev81887. -- ___ Python tracker ___ ___

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

A.M. Kuchling added the comment: Demo/embed/demo.c calls PySys_SetArgv(), which may be where some people are copying their code from. I've updated it to use PySys_SetArgvEx() and added an explanatory comment in rev. 81881. -- nosy: +akuchling ___ Py

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

Antoine Pitrou added the comment: Committed in r81398 (trunk), r81399 (2.6), r81400 (py3k), r81401 (3.1). Thank you! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

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

Antoine Pitrou added the comment: > Absolute path to the directory where script is located. And I believe > there's no absolute path guarantee for platforms without realpath / > GetFullPathName. Yes, this is more precise indeed. As for realpath(), I would expect it to be present on modern Unic

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

Tomas Hoger added the comment: + - If the name of an existing script is passed in ``argv[0]``, its absolute + path is prepended to :data:`sys.path` Absolute path to the directory where script is located. And I believe there's no absolute path guarantee for platforms without realpath / G

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

Antoine Pitrou added the comment: Here is a new patch giving more details in the doc, and explicitly mentioning the CVE entry. -- stage: needs patch -> patch review Added file: http://bugs.python.org/file17418/setargvex2.patch ___ Python tracker

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

Tomas Hoger added the comment: > My reading of PySys_SetArgv is that if argv is NULL, then > "char *argv0 = argv[0];" will read through NULL and thus will > segfault on a typical platform. Right. > I favor Antoine's approach in > http://bugs.python.org/file13860/setargvex.patch of adding a ne

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

Antoine Pitrou added the comment: Ok, I will try to write better documentation. -- versions: +Python 3.2 -Python 3.0 ___ Python tracker ___ __

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

Dave Malcolm added the comment: Attempting to summarize IRC discussion about this. PySys_SetArgv is used to set up sys.argv There is plenty of code which assumes that this is a list containing at least a zeroth string element; for example warnings.warn (see msg89688). It seems reasonable f

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

R. David Murray added the comment: FWIW I agree with Antoine. -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mai

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

Antoine Pitrou added the comment: > Can anyone move this to Stage: patch review (for the fix approach > proposed in msg90336)? Or does anyone have better idea on how to move > this closer to final fix or wontfix / reject? Thank you! I stand by my opinion that adding another hack in the initia

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

Tomas Hoger added the comment: Can anyone move this to Stage: patch review (for the fix approach proposed in msg90336)? Or does anyone have better idea on how to move this closer to final fix or wontfix / reject? Thank you! -- ___ Python tracker

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

Tomas Hoger added the comment: Has anyone else had an opportunity to have a look at the change proposed in #msg90336? -- ___ Python tracker ___ _

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

Changes by Dave Malcolm : -- nosy: +dmalcolm ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

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

Tomas Hoger 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]))

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

Jan Lieskovsky 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

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

Antoine Pitrou 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. -

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

Antoine Pitrou 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 r

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

Tomas Hoger 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

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

Antoine Pitrou 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 m

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

Tomas Hoger 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 ||

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

Antoine Pitrou 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

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

Jan Lieskovsky 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 Liesko

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

Tanaka Akira added the comment: src/if_python.c in vim-7.2 has a comment: /* Set sys.argv[] to avoid a crash in warn(). */ I think the crash is follows. % python Python 2.5.2 (r252:60911, Jan 4 2009, 17:40:26) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more in

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

Antoine Pitrou added the comment: It seems other projects are already fighting with the path-changing behaviour of PySys_SetArgv(), e.g.: - py2exe: http://www.google.com/codesearch/p?hl=fr#QCS1naFbAGM/trunk/py2exe/source/start.c&q=PySys_SetArgv - gtk: http://www.google.com/codesearch/p?hl=fr#4d1

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

Gregory P. Smith added the comment: re: gedit """I'm by no means an expert (I did not design the original python module extension), we simply copied from vim at the beginning. That said, it seems there are issues if you embed the python interpreter and do not explicitly set sys.argv to somet

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

Gregory P. Smith added the comment: gedit does it here: http://git.gnome.org/cgit/gedit/tree/plugin-loaders/python/gedit-plugin- loader-python.c#n542 I've emailed the file's author (Jesse) out of the blue to see if he knows why PySys_SetArgv() was called. --

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

Glyph Lefkowitz added the comment: > IOW, I *really* want to understand what's happening before fixing > it. This is a security issue, after all. Agreed. Does anyone currently subscribed to this ticket know the author of such an application? It would be very helpful to have them involved in t

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

Martin v. Löwis added the comment: > It suggests to me that somewhere there's some documentation, or an > example, that says "this is the right way to embed python, call this > function". That may be an explanation. However, it would be immensely useful to know for sure, from the original autho

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

Glyph Lefkowitz added the comment: It suggests to me that somewhere there's some documentation, or an example, that says "this is the right way to embed python, call this function". If the right thing to do is to just not call the function at all, we need to get that knowledge out there into th

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

Martin v. Löwis added the comment: I wonder why all these applications call PySys_SetArgv at all if they don't have any arguments to set. In the gedit case, I just removed the call from gedit, and it seems to work fine (sys.argv will be an empty list). -- __

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

Antoine Pitrou added the comment: > The question is whether these are theoretical or real problems. > I ran gedit (as proposed by Glyph) under strace(1), and it didn't > try to open any files in the current directory. You have to use a Python-written gedit plugin for that to happen. For example

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

Antoine Pitrou added the comment: Hello Jan, > 1, doesn't avoid the need to fix the issue (by calling > "PySys_SetArgvEx(argc, argv, 0);") in all current applications embedding > Python, As you said yourself, we don't want to break backwards compatibility for C API users -- especially between

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

Martin v. Löwis added the comment: > What's the question of 'security nature' of the issue, Glyph in > message #msg86927 already uncovered potential implications -- The question is whether these are theoretical or real problems. I ran gedit (as proposed by Glyph) under strace(1), and it didn't

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

Jan Lieskovsky added the comment: Antoine, (re: #msg87083, #msg87084) -- while the API change is acceptable and reasonable, it doesn't solve the core of the problem. I understand the change needs to be 'backward compatible' and shouldn't break the existing Python behavior, but the current pro

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

Changes by Antoine Pitrou : -- priority: release blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

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

Antoine Pitrou added the comment: Ok, downgrading to critical. I'm awaiting the reporter's answer anyway. -- ___ Python tracker ___ __

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

Martin v. Löwis added the comment: I disagree that this issue is release critical. I'm still skeptical that this is a security bug; if it is, any solution created needs to be applied to all active branches - including the ones that would be blocked by this issue right now. IOW, it's still possib

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

Antoine Pitrou added the comment: Jan, would the new API be ok to you? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

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

Antoine Pitrou added the comment: Here is a patch for trunk. -- Added file: http://bugs.python.org/file13860/setargvex.patch ___ Python tracker ___ __

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

Changes by Antoine Pitrou : -- nosy: +barry, benjamin.peterson priority: critical -> release blocker stage: test needed -> needs patch versions: +Python 2.6, Python 3.0 ___ Python tracker ___

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

Antoine Pitrou added the comment: By the way, the advantage of a new function over a behaviour change is that the new function could safely be backported to 2.6.3, since it is also a "security fix". -- ___ Python tracker

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

Gregory P. Smith added the comment: both the behavior change and PySys_SetArgvEx() with an additional boolean parameter sounds good to me. Some people may disagree about changing the default behavior. So long as its documented in the whatsnew I personally think it is fine. But would doing tha

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

Antoine Pitrou added the comment: I'm not sure we can change the behaviour of PySys_SetArgv() like that. At least not in a bugfix release. In 2.7/3.1, we could either change PySys_SetArgv(), or introduce a new PySys_SetArgvEx() with an additional argument indicating whether sys.path should be mo

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

Glyph Lefkowitz added the comment: Antoine, The problem is that apparently every program that embeds Python calls PySys_SetArgv and does not understand the consequences of doing so. For example, a user running 'gedit' to edit some files in a potentially insecure directory may not expect that s

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

Antoine Pitrou added the comment: I wanted to read the patch at https://bugzilla.redhat.com/attachment.cgi?id=334888 but apparently its access is restricted... -- ___ Python tracker

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

Antoine Pitrou added the comment: What is the problem exactly? An user can run arbitrary Python code from a file in his own account -- well, sure, that's a feature. Unless I'm misunderstanding something. -- nosy: +pitrou ___ Python tracker

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

Changes by Glyph Lefkowitz : -- nosy: +glyph ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

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

Changes by Daniel Diniz : -- priority: -> critical stage: -> test needed ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

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

Changes by Petr Splichal : -- nosy: +psss ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

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

Jan Lieskovsky added the comment: Just drop into /tmp and run (you will need the zenity package installed): python3.1 ./test.py or gedit# unfixed gedit in that directory. -- Added file: http://bugs.python.org/file13686/py_umspath_test.tar.gz ___

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

Jan Lieskovsky added the comment: As no longer work of "python ./foo.py" after patch utilization may cause, the update won't be acceptable, could you guys review the above patch and potentially provide an another one? -- ___ Python tracker

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

Jan Lieskovsky added the comment: To sum up the behavior, the following table displays whether modules are read from the current working directory for various ways how the python scripts can be launched (unfixed/fixed version): unfixed fixed run as ~~

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

New submission from Jan Lieskovsky : Common Vulnerabilities and Exposures assigned an identifier CVE-2008-5983 (and related CVE ids) to the following vulnerability: Untrusted search path vulnerability in the PySys_SetArgv API function in Python 2.6 and earlier, and possibly later versions, prepe