Bug 978696 - (CVE-2013-2217) CVE-2013-2217 python-suds: Insecure temporary directory use when initializing file-based URL cache
CVE-2013-2217 python-suds: Insecure temporary directory use when initializing...
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20130627,reported=2...
: Security
Depends On: 1072071 979066 979069 979070
Blocks: 994246 979073
  Show dependency treegraph
 
Reported: 2013-06-27 01:03 EDT by Ralph Loader
Modified: 2016-05-24 04:50 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1072071 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fix for insecure cache path (562 bytes, patch)
2013-06-29 11:23 EDT, mbehrle
no flags Details | Diff
Current patch used in Debian taken from suds-jurko (8.53 KB, application/octet-stream)
2015-05-27 12:01 EDT, mbehrle
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 726893 None None None Never

  None (edit)
Description Ralph Loader 2013-06-27 01:03:51 EDT
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 01:12:48 EDT
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 01:21:13 EDT
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 01:45:22 EDT
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 10:01:54 EDT
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 10:07:56 EDT
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 10:20:50 EDT
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 10:24:07 EDT
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 10:32:47 EDT
CVE Request:
  http://www.openwall.com/lists/oss-security/2013/06/27/5
Comment 11 Vincent Danen 2013-06-27 23:48:48 EDT
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 02:36:25 EDT
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 11:23:27 EDT
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 12:01:06 EDT
Created attachment 1030681 [details]
Current patch used in Debian taken from suds-jurko

Note You need to log in before you can comment on or make changes to this bug.