Bug 978696 (CVE-2013-2217)

Summary: CVE-2013-2217 python-suds: Insecure temporary directory use when initializing file-based URL cache
Product: [Other] Security Response Reporter: Ralph Loader <suckfish>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: anrussel, jaroslaw.polok, jlieskov, jortel, jrusnack, mbehrle, sauchter
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1072071 (view as bug list) Environment:
Last Closed: 2019-06-10 11:00:50 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 979066, 979069, 979070, 1072071    
Bug Blocks: 979073, 994246    
Attachments:
Description Flags
Fix for insecure cache path
none
Current patch used in Debian taken from suds-jurko none

Description Ralph Loader 2013-06-27 05:03:51 UTC
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.]

Comment 1 Ralph Loader 2013-06-27 05:12:48 UTC
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.

Comment 2 Ralph Loader 2013-06-27 05:21:13 UTC
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.

Comment 3 Ralph Loader 2013-06-27 05:45:22 UTC
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.

Comment 4 Jan Lieskovsky 2013-06-27 14:01:54 UTC
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.]

Comment 5 Jan Lieskovsky 2013-06-27 14:07:56 UTC
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.

Comment 6 Jan Lieskovsky 2013-06-27 14:20:50 UTC
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.

Comment 9 Jan Lieskovsky 2013-06-27 14:24:07 UTC
Created python-suds tracking bugs for this issue:

Affects: fedora-all [bug 979069]
Affects: epel-all [bug 979070]

Comment 10 Jan Lieskovsky 2013-06-27 14:32:47 UTC
CVE Request:
  http://www.openwall.com/lists/oss-security/2013/06/27/5

Comment 11 Vincent Danen 2013-06-28 03:48:48 UTC
This was assigned CVE-2013-2217:

http://www.openwall.com/lists/oss-security/2013/06/27/8

Comment 12 Huzaifa S. Sidhpurwala 2013-06-28 06:36:25 UTC
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.

Comment 14 mbehrle 2013-06-29 15:23:27 UTC
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.

Comment 17 mbehrle 2015-05-27 16:01:06 UTC
Created attachment 1030681 [details]
Current patch used in Debian taken from suds-jurko

Comment 19 Ralph Loader 2018-03-11 03:31:14 UTC
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.