Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 256619 (CVE-2008-5983) - <dev-lang/python-{2.6.6-r1,2.7.1-r1,3.1.3-r1}: PySys_SetArgv() Untrusted search path vulnerability (CVE-2008-5983)
Summary: <dev-lang/python-{2.6.6-r1,2.7.1-r1,3.1.3-r1}: PySys_SetArgv() Untrusted sear...
Alias: CVE-2008-5983
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Gentoo Security
Whiteboard: A2 [glsa]
Keywords: Tracker
Depends on:
Blocks: CVE-2008-5985 CVE-2008-5987 CVE-2009-0314 CVE-2009-0315 CVE-2009-0316 CVE-2009-0317 CVE-2009-0318 CVE-2008-5984 CVE-2010-0668
  Show dependency tree
Reported: 2009-01-28 12:13 UTC by Robert Buchholz (RETIRED)
Modified: 2014-01-06 22:03 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2009-01-28 12:13:36 UTC
CVE-2008-5983 (
  Untrusted search path vulnerability in the PySys_SetArgv API function
  in Python before 2.6 prepends an empty string to sys.path when the
  argv[0] argument does not contain a path separator, which might allow
  local users to execute arbitrary code via a Trojan horse Python file
  in the current working directory.
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2009-01-30 23:46:19 UTC
Applications that trigger this vulnerability by calling PySys_SetArgv with a non-None argv need to make sure their sys.path is clean. An examplary patch can be found here:;filename=sanitize_sys.path.diff;att=1;bug=504363
Comment 2 Mart Raudsepp gentoo-dev 2009-01-30 23:58:18 UTC
Isn't it better to make python behave better here to not allow for such an easy security mistake?
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2009-01-31 01:47:42 UTC
There is a Gnome tracker bug for all their applications:

(In reply to comment #2)
> Isn't it better to make python behave better here to not allow for such an
> easy security mistake?

Yes, this behaviour is not properly specified in the API and some applications now hit this trap. However, changing behaviour always has the risk of other applications breaking, because they implicitly rely on it.
Personally, I'd prefer fixing those applications that rely on this fluke rather than having others add special handlers themselves, but this seems best decided by Python upstream or our maintainers. I am not aware whether this discussion has been brought to them, but there are some comments already in other trackers:
Comment 4 Sergey Popov gentoo-dev 2014-01-06 22:03:32 UTC
Covered by GLSA 201401-04

Closing as fixed