Bug 892909 (CVE-2013-0163)

Summary:	CVE-2013-0163 OpenShift haproxy cartridge: predictable /tmp in set-proxy connection hook
Product:	[Other] Security Response	Reporter:	Kurt Seifried <kseifried>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	bleanhar, bperkins, calfonso, ccoleman, dmcphers, jialiu, jkeck, jlieskov, jokerman, jrusnack, kseifried, lmeyer, mmccomas, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-09-06 05:37:24 UTC	Type:	---
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:	892053, 928257
Bug Blocks:	767033, 872346, 893314

Description Kurt Seifried 2013-01-08 08:36:35 UTC

Michael Scherer (misc) of Red Hat reports:

Description of problem:

In the connection hooks set by using a scaled application :
https://github.com/openshift/origin-server/blob/master/cartridges/openshift-origin-cartridge-haproxy-1.4/info/connection-hooks/set-proxy#L63

 the following code is used :

   cp -f "$haproxy_cfg" /tmp/haproxy.cfg.$$
   sed -i "/\s*server\s*gear-${gear_name}\s.*/d" /tmp/haproxy.cfg.$$
   cat /tmp/haproxy.cfg.$$ > "$haproxy_cfg"
   rm -f /tmp/haproxy.cfg.$$

If someone manage to be able to create enough directories in /tmp/ ( like 
/tmp/haproxy.cfg.1 to 65000, with a for loop ), since the code never check 
any return code of the binary, the haproxy configuration will be erased at 
the 3rd line of the snippet, resulting in a DoS.

Another possibility is using enough file in /tmp with 444 mode, so cp would 
not be able to erase it, but cat would still copy it in the haproxy 
configuration, thus permitting to inject anything into haproxy configuration 
( I can imagine someone redirecting trafic to the wrong host, etc ).

This code is called when the application is scaled, if I understand well the 
documentation. However, I do not know if this can be triggered externally and 
how. In doubt, I will consider this as a security issue, and let the SRT judge
if that's right or not

You will find a non tested patch attached to this bug report against latest 
HEAD. instead of copying and then modifying using sed, it would be better to 
directly modify the file. I am not sure the code is correct as I suspect it 
may fail in weird in case of concurrent editing, but I think the previous one 
would also had a issue with that case.

As all others bug I opened this evening/afternoon, this is mitigated by the 
usage of polyinstanciated /tmp directory on openshift online, so the problem 
would just be for enterprise users who do not follow the security 
recommendation ( or people setting up origin by themselves ).

Comment 3 Murray McAllister 2013-09-17 14:45:40 UTC

Acknowledgements:

This issue was discovered by Michael Scherer of the Red Hat Regional IT team.

Comment 5 Kurt Seifried 2014-01-08 05:09:50 UTC

So in total we have:

./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        cp -f "$haproxy_cfg" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        sed -i "/$1/ s#\$# disabled#g" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        cat /tmp/haproxy.cfg.$$ > "$haproxy_cfg"
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        rm -f /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        cp -f "$haproxy_cfg" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        sed -i "/$1/ s#disabled\$##g" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        cat /tmp/haproxy.cfg.$$ > "$haproxy_cfg"
./openshift-origin-cartridge-haproxy-1.17.3/bin/control:        rm -f /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/fix_local.sh:     cp -f $haproxy_cfg /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/fix_local.sh:     sed -i "/\s*server\s*local-gear\s.*/d" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/fix_local.sh:     echo "    server local-gear $local_ep weight 0" >> /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/fix_local.sh:     cat /tmp/haproxy.cfg.$$ > "$haproxy_cfg"
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/fix_local.sh:     rm -f /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:cp -f "$haproxy_cfg" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:        sed -i "/\s*server\s*gear-$sg\s.*/d" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:sed -i "/\s*server\s*local-gear\s.*/d" /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:echo "    server local-gear $local_ep check fall 2 rise 3 inter 2000 cookie local-$OPENSHIFT_GEAR_UUID" >> /tmp/haproxy.cfg.$$
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:cat /tmp/haproxy.cfg.$$ > "$haproxy_cfg"
./openshift-origin-cartridge-haproxy-1.17.3/usr/bin/update-cluster:rm -f /tmp/haproxy.cfg.$$

Comment 6 Brenton Leanhardt 2014-01-10 16:25:09 UTC

Wow, this bug is over a year old. :(.  Looks like the set-proxy and fix-local.sh script need to be updated.  This bug affects OSE 2.0 too so we should probably have a tracking bug there as well.

Comment 9 Kurt Seifried 2014-09-06 05:36:39 UTC

Statement:

This issue affects the versions of the haproxy cartridge as shipped with Red Hat OpenShift Enterprise 1 and 2. Red Hat Product Security has rated this issue as having Low security impact. A future update may address this issue. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/. Additionally OpenShift uses a per user poly-instantiated /tmp directory which makes exploitation of this issue very difficult.

Comment 10 Ján Rusnačko 2015-10-23 15:11:42 UTC

I edited statement in comment 9 and making comment 8 private.