From ${URL} : based on the public Red Hat Bugzilla report: [1] https://bugzilla.redhat.com/show_bug.cgi?id=978696 by Ralph Loader: A insecure temporary directory use flaw was found in the way python-suds, a Python SOAP web services client library, performed initialization of its internal file-based URL cache (predictable location was used for directory to store the cached files). A local attacker could use this flaw to conduct symbolic link attacks, possibly leading to their ability for example the SOAP .wsdl metadata to redirect queries to a different host, than originally intended. The reasons for the current behaviour are detailed at: [2] https://bugzilla.redhat.com/show_bug.cgi?id=978696#c4 @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
P.S.: There doesn't seem to be an upstream patch available yet (afaik), but the fix is obvious. This messes with Python's tempfile.gettempdir() which has tripped up many a python testsuite. Use of /tmp causes havoc with running the ebuild process as user for starters. Could you prompt on the occasion of upstream making a proper patch apt for any distro.
Proposed fix from Red Hat bugzie at [1]. Your call, Python team. [1] https://bugzilla.redhat.com/attachment.cgi?id=766910&action=diff
LGTM. Anyone wants to work through this?
CVE-2013-2217 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2217): cache.py in Suds 0.4, when tempdir is set to None, allows local users to redirect SOAP queries and possibly have other unspecified impact via a symlink attack on a cache file with a predictable name in /tmp/suds/.
This seems to be a somewhat active fork, that fixes the vulnerability and has new releases (currently v0.6): https://bitbucket.org/jurko/suds/
(In reply to Manuel Rüger from comment #5) > This seems to be a somewhat active fork, that fixes the vulnerability and > has new releases (currently v0.6): https://bitbucket.org/jurko/suds/ A fork of the same name? What happens here (after 2 years)? A fork is generally renamed and is distinguishable. In this case changing HOMEPAGE and SRC_URI might be 'wrong'.
(In reply to Manuel Rüger from comment #5) > This seems to be a somewhat active fork, that fixes the vulnerability and > has new releases (currently v0.6): https://bitbucket.org/jurko/suds/ Here is the patch, but it doesn't apply cleanly to version 0.4. https://bitbucket.org/jurko/suds/commits/3126ac3a406c37f9982f01ad0ca4ed42cf9a47cb/raw/
(In reply to Ian Delaney from comment #6) > (In reply to Manuel Rüger from comment #5) > > This seems to be a somewhat active fork, that fixes the vulnerability and > > has new releases (currently v0.6): https://bitbucket.org/jurko/suds/ > > A fork of the same name? What happens here (after 2 years)? A fork is > generally renamed and is distinguishable. In this case changing HOMEPAGE > and SRC_URI might be 'wrong'. it is called suds-jurko at some places.
I've bumped suds to be suds-jurko now (0.6). we do a stablereq here for that?
As previously mentioned, the package was "forked" under the same cat/package. The new code in >=dev-python/suds-0.6 is not vulnerable, which has been confirmed. @maintainer(s), please drop the vulnerable 0.4 ebuild, which pulls in the old code base.
@maintainer(s), please cleanup the vulnerable version still in tree.
Cleaned: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce2ee59070980eded4044d8629b1b00ac67ee5fa GLSA Vote: No
