python-suds creates and uses some sort of cache in /tmp/suds. It appears to make no attempt to check that the cache is not created or modified by a different user. After running a SOAP request using suds, I notice the /tmp/suds directory. I chown'd -R /tmp/suds to a different user, and chmod'd -R 777. Then stracing the script sending soap requests with python-suds, and I see: stat("/tmp/suds/suds-3359686402328425149-document.px", {st_mode=S_IFREG|0777, open("/tmp/suds/suds-3359686402328425149-document.px", O_RDONLY) = 3 read(3, "\200\2(csuds.sax.document\nDocument\nq"..., 4096) = 4096 [I note that even if python-suds were inspecting the stat result at some later point to check user & permissions, and reading-but-ignoring the contents of the /tmp file there would still be a toq-tau race.] I haven't verified the details, but presumably if you know what SOAP services another user is using, you can then create a /tmp/suds/ directory to do nasty things to them. [For instance the SOAP .wsdl metadata can redirect queries to a different host.]
The files (apart from the version file) are python pickle data. The python pickle documentation warns: "Warning The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source." The data in the files appear to be an XML schema of SOAP service.
And in the cache we do find the .wsdl. Containing lines like: <soap:address location="https://192.168.132.10/services/fwif/"/> This means if you can write a cache that someone else then uses, you can redirect their SOAP requests anywhere you like, and e.g. steal their credentials.
Suds appears to have some sort of API for setting the cache location. So in theory it might be possible for a program using suds to configure the suds library to be secure. I downloaded and unpacked the following packages that use (directly or indirectly) suds: chirp-0:0.3.1-1.fc19.noarch condor-aviary-common-0:7.9.5-0.2.fc19.x86_64 condor-aviary-hadoop-common-0:7.9.5-0.2.fc19.x86_64 cumin-0:0.1.5739-1.fc19.noarch fence-agents-vmware-soap-0:4.0.0-3.fc19.x86_64 imagefactory-0:1.1.2-1.fc19.noarch python-psphere-0:0.1.4-4.fc19.noarch python-vatnumber-0:1.0-4.fc19.noarch virt-who-0:0.8-7.fc19.noarch imagefactory-0:1.1.2-1.fc19.noarch openerp-0:6.1-4.20130126_002033.fc19.noarch trytond-party-0:2.6.0-2.fc19.noarch Then grepping for likely things, it appears that "cumin" disables the cache at least in one place, an is likely not effected: cumin/usr/share/cumin/python/sage/aviary/aviarylocator.py: client = OverrideClient(self.wsdl, cache=None) As far as I can see, none other packages modify the default suds caching behaviour in any way.
Thank you for your report, Ralph. Good catch. (In reply to Ralph Loader from comment #0) > python-suds creates and uses some sort of cache in /tmp/suds. It appears to > make no attempt to check that the cache is not created or modified by a > different user. The problem seems to be due the following code lines (rpmbuild/BUILD/python-suds-0.4.1/suds/cache.py): 23 from tempfile import gettempdir as tmp 117 class FileCache(Cache): 118 """ 119 A file-based URL cache. 120 @cvar fnprefix: The file name prefix. 121 @type fnsuffix: str 122 @ivar duration: The cached file duration which defines how 123 long the file will be cached. 124 @type duration: (unit, value) 125 @ivar location: The directory for the cached files. 126 @type location: str 127 """ 128 fnprefix = 'suds' 129 units = ('months', 'weeks', 'days', 'hours', 'minutes', 'seconds') 130 131 def __init__(self, location=None, **duration): 132 """ 133 @param location: The directory for the cached files. 134 @type location: str 135 @param duration: The cached file duration which defines how 136 long the file will be cached. A duration=0 means forever. 137 The duration may be: (months|weeks|days|hours|minutes|seconds). 138 @type duration: {unit:value} 139 """ 140 if location is None: 141 location = os.path.join(tmp(), 'suds') 142 self.location = location 143 self.duration = (None, 0) 144 self.setduration(**duration) 145 self.checkversion() From tempfile.gettempdir() documentation: http://docs.python.org/2/library/tempfile.html "tempfile.gettempdir() Return the directory currently selected to create temporary files in. If tempdir is not None, this simply returns its contents; otherwise, the search described above is performed, and the result returned." since 'tempdir' is None, search described in 'tempfile.tempdir' is performed, which for Unix / Linux platforms means 'tempfile.gettempdir()' returns '/tmp', which subsequently results into above described "/tmp/suds" being used as a file-based URL cache location. > > After running a SOAP request using suds, I notice the /tmp/suds directory. > I chown'd -R /tmp/suds to a different user, and chmod'd -R 777. > > Then stracing the script sending soap requests with python-suds, and I see: > > stat("/tmp/suds/suds-3359686402328425149-document.px", > {st_mode=S_IFREG|0777, > open("/tmp/suds/suds-3359686402328425149-document.px", O_RDONLY) = 3 > read(3, "\200\2(csuds.sax.document\nDocument\nq"..., 4096) = 4096 > > [I note that even if python-suds were inspecting the stat result at some > later point to check user & permissions, and reading-but-ignoring the > contents of the /tmp file there would still be a toq-tau race.] > > I haven't verified the details, but presumably if you know what SOAP > services another user is using, you can then create a /tmp/suds/ directory > to do nasty things to them. [For instance the SOAP .wsdl metadata can > redirect queries to a different host.]
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.
This issue affects the versions of the python-suds package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue affects the versions of the python-suds package, as shipped with Fedora release of 17 and 18. Please schedule an update once there is final upstream patch available. -- This issue affects the versions of the python-suds package, as shipped with Fedora EPEL-5 and Fedora EPEL-6. Please schedule an update once there is final upstream patch available.
Created python-suds tracking bugs for this issue: Affects: fedora-all [bug 979069] Affects: epel-all [bug 979070]
CVE Request: http://www.openwall.com/lists/oss-security/2013/06/27/5
This was assigned CVE-2013-2217: http://www.openwall.com/lists/oss-security/2013/06/27/8
Statement: This issue affects the version of python-suds as shipped with Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.
Created attachment 766910 [details] Fix for insecure cache path Preliminary fix to create cache directory in a secure way. Lacks cleanup of cache dirs after program termination.
Created attachment 1030681 [details] Current patch used in Debian taken from suds-jurko
Given the length of time that has passed, I presume that the upstream is derelict and no longer making any attempt to process security issues. If that is the case, then I suggest the package be dropped from RedHat and Fedora.