Bug 1009103 (CVE-2013-6501)

Summary: CVE-2013-6501 php: predictable file name used for cache in world writeable directory
Product: [Other] Security Response Reporter: Michael S. <misc>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: bgollahe, bleanhar, carnil, ccoleman, dmcphers, drieden, falonso, huzaifas, jdetiber, jialiu, jkeck, jkurik, joelsmith, jokerman, jorton, kseifried, lmeyer, mmaslano, mmccomas, mmcgrath, nobody+bgollahe, pfrields, rcollet, security-response-team, tdawson, vdanen, webstack-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
It was found that the PHP WSDL extension used a file with a predictable name in a world readable directory as a cache. A local attacker could use this flaw to poison the cache using a specially crafted temporary file.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-14 10:07:17 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:    
Bug Blocks: 1012158    

Description Michael S. 2013-09-17 17:08:04 UTC 
On http://git.php.net/?p=php-src.git;a=blob;f=ext/soap/php_sdl.c;h=0ac4c2ed7a9bf87bb454db58ae3d969eef36f244;hb=HEAD#l3224

We see that php wdsl extension is reading predictible filename from a cache directory. The name is based on a configurable directory name, a prefix, and a md5, md5 derived for the file that would be cached ( or rather the url ).

So far, so good. However, default configuration is to use /tmp :
http://www.php.net/manual/en/soap.configuration.php#ini.soap.wsdl-cache-dir

so someone could connect to a shared php server ( not uncommon ), and if some php code is using this feature ( ie, using wsdl ), with cache enabled by default ,it could just pre-create the file in /tmp to have it used instead of the one intended to be used ( ie, a cache injection issue ). After a quick look, there is no check of owner or permission in get_sdl_from_cache.

I am not able to say if WSDL injection is a serious issue or not.

Fedora do have PrivateTmp in systemd file, that mitigate this issue ( provided someone do not use php to make the attack ). RHEL < 7 do not have it however.

So far, upstream was not notified, except our php maintainer for a quick sanity check. I assume this affect all php version since a few years.
Comment 2 Michael S. 2013-09-17 18:23:52 UTC 
So looking a bit more on WSDL, I see that WDSL also include a description of endpoint of the service ( see :
<definitions .... >
 <service name="service1">
        <port name="port1" binding="tns:b1">
           <http:address location="http://example.com/"/>
        </port>

So someone injecting a WSDL file could also inject a different endpoint ( ie, a http url ) which would then be a bit more serious, since that mean someone could just redirect a web service to a different server.

Then the software would try to execute remote code on the wrong remote server, which mean :
- stealing argument value
- injecting wrong results
Comment 3 Vincent Danen 2013-09-18 04:09:15 UTC 
Michael, can you send an email to security with the above?  This does sound like a security issue to me, but I can't say how severe it is.  This may or may not be "arbitrary code" (i.e. you can define by the wsdl what code to execute on the remote server), but you could use it to do some kind of "pinging" to a remote server when the wsdl is called.  I'll admit that I don't know much about this so I'm not sure how bad it is.

Thanks.
Comment 5 Michael S. 2013-09-18 11:18:24 UTC 
Done, i sent the email ( as you likely have seen ) and added rcollet@ since he wanted to comment on it ( and is our php packager )
Comment 11 Kurt Seifried 2015-02-08 22:19:43 UTC 
This has been made public and PHP re-notified.
Comment 12 Francisco Alonso 2015-03-17 09:59:02 UTC 
Additional references:

http://www.openwall.com/lists/oss-security/2015/02/08/5
http://www.openwall.com/lists/oss-security/2015/02/08/7
Comment 13 Francisco Alonso 2015-03-17 11:30:03 UTC 
Acknowledgements:

This issue was discovered by Michael Scherer of Red Hat.