Bug 892909 (CVE-2013-0163) - CVE-2013-0163 OpenShift haproxy cartridge: predictable /tmp in set-proxy connection hook
Summary: CVE-2013-0163 OpenShift haproxy cartridge: predictable /tmp in set-proxy conn...
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2013-0163
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 892053 928257
Blocks: 767033 872346 893314
TreeView+ depends on / blocked
 
Reported: 2013-01-08 08:36 UTC by Kurt Seifried
Modified: 2023-05-12 17:19 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-06 05:37:24 UTC
Embargoed:


Attachments (Terms of Use)

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.


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