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 569214 - gedit: untrusted python modules search path
gedit: untrusted python modules search path
Product: libpeas
Classification: Platform
Component: python
Other Linux
: Normal normal
: ---
Assigned To: libpeas-maint
Depends on:
Blocks: 569273
Reported: 2009-01-26 17:29 UTC by Ray Strode [halfline]
Modified: 2010-07-22 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

not yet tested patch (714 bytes, patch)
2009-01-26 18:21 UTC, Ray Strode [halfline]
rejected Details | Review
Test case. (67 bytes, text/plain)
2009-01-26 19:02 UTC, Ray Strode [halfline]
one line patch (1.21 KB, patch)
2009-01-26 21:19 UTC, Ray Strode [halfline]
none Details | Review
Prevent having untrusted python modules in search path (1.01 KB, patch)
2010-07-22 11:54 UTC, Garrett Regier
accepted-commit_now Details | Review

Description Ray Strode [halfline] 2009-01-26 17:29:58 UTC
(From Jan Lieskovsky,

"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.


Debian bug report for similar eog issue:

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:;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".
Comment 1 Ray Strode [halfline] 2009-01-26 18:21:37 UTC
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.
Comment 2 Ray Strode [halfline] 2009-01-26 19:02:46 UTC
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.
Comment 3 Ray Strode [halfline] 2009-01-26 19:04:31 UTC
The above test case confirms that python 2.6 is affected.
Comment 4 Ray Strode [halfline] 2009-01-26 19:23:10 UTC
testing seems to show that attachment 127279 [details] doesn't fix the issue.
Comment 5 Ray Strode [halfline] 2009-01-26 21:19:28 UTC
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.
Comment 6 Paolo Borelli 2009-01-27 08:43:43 UTC
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.
Comment 7 Ray Strode [halfline] 2009-01-27 14:37:09 UTC
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.
Comment 8 Jan Lieskovsky 2009-01-28 10:39:36 UTC
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).

Comment 9 Ray Strode [halfline] 2009-01-28 14:34:29 UTC
See for the root python issue.
Comment 10 Josselin Mouette 2009-02-02 15:41:38 UTC
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.
Comment 11 Ray Strode [halfline] 2009-02-04 14:39:48 UTC
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).
Comment 12 Josselin Mouette 2009-02-04 15:55:48 UTC
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.
Comment 13 Sebastien Bacher 2009-04-07 21:26:07 UTC
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
Comment 14 Ray Strode [halfline] 2009-04-08 15:27:09 UTC
I think the feeling was that this should get fixed in python instead.
Comment 15 Josselin Mouette 2009-04-08 15:30:45 UTC
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.
Comment 16 Ray Strode [halfline] 2009-04-08 15:41:39 UTC
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.
Comment 17 Paolo Borelli 2009-04-12 15:55:43 UTC
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.
Comment 18 Jan Lieskovsky 2009-04-14 12:04:50 UTC
Link to Python tracker:
Comment 19 Paolo Borelli 2010-06-27 19:53:52 UTC
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)
Comment 20 Steve Frécinaux 2010-07-22 11:13:02 UTC
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?
Comment 21 Garrett Regier 2010-07-22 11:54:12 UTC
Created attachment 166381 [details] [review]
Prevent having untrusted python modules in search path
Comment 22 Steve Frécinaux 2010-07-22 12:11:07 UTC
Review of attachment 166381 [details] [review]:

You can commit now, but don't forget to add the bug url in the commit message.
Comment 23 Garrett Regier 2010-07-22 13:13:06 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.