GNOME Bugzilla – Bug 569214
gedit: untrusted python modules search path
Last modified: 2010-07-22 13:13:06 UTC
(From Jan Lieskovsky, https://bugzilla.redhat.com/show_bug.cgi?id=481556) "Untrusted search path vulnerability in gedit's Python module 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: http://www.nabble.com/Bug-484305%3A-bicyclerepair%3A-bike.vim-imports-untrusted-python-files-from-cwd-td18848099.html Debian bug report for similar eog issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504352#4 Proposed patch: Not sure, if gedi'ts upstream has been reported about this issue. The Debian patch for similar eog's Python related issue, available at: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=02_sanitize_sys.path.patch;att=1;bug=504352 should be sufficient to resolve this issue." There's no CVE assigned yet, but one has been requested. The security severity is considered "low".
Created attachment 127273 [details] [review] not yet tested patch This patch is basically the EOG patch mentioned above, but for gedit. I haven't tested it yet.
Created attachment 127279 [details] Test case. Drop into /tmp and then run gedit from /tmp. I had the Python Console plugin enabled at the time.
The above test case confirms that python 2.6 is affected.
testing seems to show that attachment 127279 [details] doesn't fix the issue.
Created attachment 127294 [details] [review] one line patch I also tried to doing the equivalent code in C using Py_GetPath, PySys_SetPath (and filtering with a GPtrArray, g_strsplit, a for loop, and g_strjoinv), but it didn't work either. The above one line patch seems to work though.
I read the original vim bugreport and I tend to agree that this should be probably fixed in python since we follow verbatim the suggested way to setup python in their docs, so this probably affect any program embedding python and should be fixed in one place. That said, if we go for the workaround, I do not like the last patch much since we've moved away from hardcoded an "plugin_dir" specified at build time (it was necessary for the win32 port). I guess we can pick another safe path... "/usr/bin/gedit" (well, $PREFIX/bin/gedit) seems a natural choice since argv[0] usually contains the binary path, and in this case we would use the absolute binary path. We just have to check that it doesn't conflit with e.g. an hypotetic "pythonconsole" program in /usr/bin... in other words I am not sure if passing the path to a binary is ok, or if we are forced to set the path to a dir.
I think it probably makes more sense to specify a path that gedit has complete control over, so the hole doesn't accidentally open up again. It could be any directory or file I guess, as long as it's not shared between projects. maybe $DATADIR/gedit ? Of course if we can get this fixed in python that's even better.
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0314 to this vulnerability: Untrusted search path vulnerability in the Python module in gedit 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-0314 http://www.openwall.com/lists/oss-security/2009/01/26/2 http://bugzilla.gnome.org/show_bug.cgi?id=569214
See https://bugzilla.redhat.com/show_bug.cgi?id=482814 for the root python issue.
The test case only checks one attack vector: shipping a file that replaces a plugin configured to run. However there is another attack vector: shipping a file that replaces a module imported by a plugin configured to run. Because of this, I think that both patches need to be applied.
Hi Josselin, I'm not sure I follow. Do you have a test case where attachment 127294 [details] [review] doesn't work? Note this bug should probably get closed NOTGNOME once python gets fixed (or maybe before).
Ah sorry, I didn’t know the strange side effects of PySys_SetArgv, so I misunderstood the purpose of the patch. After testing, I can confirm it actually fixes the issue.
is there any reason why this change doesn't get applied upstream too? it's used by fedora and debian and seems to work correctly
I think the feeling was that this should get fixed in python instead.
And this will be fixed in Python, but given the number of assumptions this breaks, it is not possible to make this change out of the blue. In the meantime, applications have to work around this bug.
I think it should be possible to fix in Python without breaking a lot of apps. I even did a patch for it that I gave to Jan (one of the guys on the Red Hat security team). Not sure what the status of it is.
for the record the reason why the workaround is not applied upstream is because in the patch the dummy path it feeds to python is fixed at compile time while gedit figures out the the python plugins path at run time these days, so the proposed patch would break on windows where the installation is relocable. I really hope python get its acts together as soon as possible... otherwise we need to figure out a different dummy path to use.
Link to Python tracker: http://bugs.python.org/issue5753
reassigning this to libpeas that now takes care of embedding python for us. Steve: note that the python bug as been fixed by providing an alternative api which we should use (maybe with some ifdef if older python version must still be supported)
The proper solution here seems to be using PySys_SetArgvEx() instead of PySys_SetArgv() for python 2.6+. Do someone feel like submitting a patch?
Created attachment 166381 [details] [review] Prevent having untrusted python modules in search path
Review of attachment 166381 [details] [review]: You can commit now, but don't forget to add the bug url in the commit message.
http://git.gnome.org/browse/libpeas/commit/?id=664d5e2ad22ac1acc39bdcf9186dc8ce734c0fcf 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.