GNOME Bugzilla – Bug 569648
Untrusted python modules search path
Last modified: 2009-02-07 19:18:53 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:
Created attachment 127446 [details] [review] patch
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.
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).
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.
Created attachment 127457 [details] [review] Fix vulnerability
Why not just use "/dev/null/python/is/buggy/gnumeric" and not filter anything?
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.
I've also applied the patch on the gnumeric-1-8 branch: http://svn.gnome.org/viewvc/gnumeric?view=revision&revision=17111
And to 1-6 as well (sorry, we're stuck with that in Debian stable...).
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.
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.
Changing to the proper status of NOTGNOME.