After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 569648 - Untrusted python modules search path
Untrusted python modules search path
Status: RESOLVED NOTGNOME
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks: 569273
 
 
Reported: 2009-01-29 11:05 UTC by Huzaifa Sidhpurwala (Red Hat Security Response)
Modified: 2009-02-07 19:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (371 bytes, patch)
2009-01-29 11:16 UTC, Huzaifa Sidhpurwala (Red Hat Security Response)
none Details | Review
Fix vulnerability (1.33 KB, patch)
2009-01-29 13:35 UTC, Jon Kåre Hellan
none Details | Review

Description Huzaifa Sidhpurwala (Red Hat Security Response) 2009-01-29 11:05:43 UTC
Please describe the problem:
Untrusted search path vulnerability in the GObject wrapper around Python
interpreter allows local users to execute arbitrary code via a Trojan horse
Python file in the current working directory, related to an erroneous
setting of sys.path by the PySys_SetArgv function.

References (more details, test case):
http://www.nabble.com/Bug-484305%3A-bicyclerepair%3A-bike.vim-imports-untrusted-python-files-from-cwd-td18848099.html

Relevant part of the code in
gnumeric-N.V.R/plugins/python-loader/gnm-py-interpreter.c:

    103         PySys_SetArgv (G_N_ELEMENTS (plugin_argv) - 1, plugin_argv);
    104         py_initgnumeric (interpreter);

Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0318 to
this vulnerability:

Untrusted search path vulnerability in the GObject Python interpreter
wrapper in Gnumeric allows local users to execute arbitrary code via a
Trojan horse Python file in the current working directory, related to
a vulnerability in the PySys_SetArgv function (CVE-2008-5983).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0318
http://www.openwall.com/lists/oss-security/2009/01/26/2


Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Huzaifa Sidhpurwala (Red Hat Security Response) 2009-01-29 11:16:17 UTC
Created attachment 127446 [details] [review]
patch
Comment 2 Jon Kåre Hellan 2009-01-29 11:55:01 UTC
Here's what sys.path looks like on my development system immediately after PyInitialize has been called:
['/usr/lib/python25.zip', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/usr/lib/python2.5/site-packages/gtk-2.0', '/var/lib/python-support/python2.5/gtk-2.0']

This is gnumeric built against python 2.5.2-2ubuntu4.1. Looks safe to me.
Comment 3 Jon Kåre Hellan 2009-01-29 12:13:42 UTC
Sorry, I was too fast. We do have the unsafe path in gnm_py_interpreter - after PySys_SetArgv at l. 104 in gnm-py-interpreter.c. The reason we are changing the argv there is r5632 by Zbigniew Chyla:

* py-gnumeric.c (create_python_interpreter): Call PySys_SetArgv after
creating new interpreter (some modules assume that sys.argv is always
set).
Comment 4 Jon Kåre Hellan 2009-01-29 13:08:47 UTC
Huzaifa's patch is OK for Linux, so go ahead and use it.
According to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504251#26,
it won't work on BSD, though. That's why vim gives a garbage path to PySys_SetArgv and explicitly filters that out of
sys.path.

vim code:
static char *(argv[2]) = {"/must>not&exist/foo", NULL};
..
PyRun_SimpleString("import sys; sys.path = 
 filter(lambda x: x != '/must>not&exist', sys.path)"

Patch coming up soon.
Comment 5 Jon Kåre Hellan 2009-01-29 13:35:59 UTC
Created attachment 127457 [details] [review]
Fix vulnerability
Comment 6 Morten Welinder 2009-01-29 13:47:58 UTC
Why not just use "/dev/null/python/is/buggy/gnumeric" and not filter anything?
Comment 7 Jon Kåre Hellan 2009-01-29 14:07:26 UTC
This problem has been fixed in the development version. The fix will be
available in the next major software release. Thank you for your bug report.
Comment 8 J.H.M. Dassen (Ray) 2009-01-29 18:17:28 UTC
I've also applied the patch on the gnumeric-1-8 branch:
	http://svn.gnome.org/viewvc/gnumeric?view=revision&revision=17111
Comment 9 J.H.M. Dassen (Ray) 2009-01-29 18:42:37 UTC
And to 1-6 as well (sorry, we're stuck with that in Debian stable...). 
Comment 10 Morten Welinder 2009-01-30 15:21:05 UTC
Just for the record:

The bug is in Python.  There was no problem with the Gnumeric code.
All we are doing here is to work around that bug until the Python people
can be bothered to fix their problem.

It would have been nice if Redhat didn't feel the need to blame us
for Python's problem.
Comment 11 Ray Strode [halfline] 2009-01-31 16:27:59 UTC
FWIW, comment 10 seems right to me, see

https://bugzilla.redhat.com/show_bug.cgi?id=482814

for the downstream "fix it in python not every app" bug.

I talked to our python maintainer (James Antill) about this a few days ago and he's looking into a fix in python.
Comment 12 Morten Welinder 2009-02-07 19:18:53 UTC
Changing to the proper status of NOTGNOME.