Description of problem: The "httpoxy" https://httpoxy.org/ vulnerability found that since CGI passes headers as environment variables, if there is header named PROXY it turns into $HTTP_PROXY... and many frameworks use that environment variable to indicate that traffic should be passed to a proxy when outgoing. This allows an attacker to interpose themselves into requests they should not see. We should consider adding a rule to screen out the header from requests we see. In general it would be nice to allow an arbitrary list of headers to be removed. So we should set up an environment variable to contain the list (separated by something) and then add a set of rules to haproxy to remove them. We should also consider whether routes can request further headers to be removed via an annotation... but we could do that later. Then we should set the default, if there is no env set, up to drop PROXY. Version-Release number of selected component (if applicable): All. How reproducible: Always. Steps to Reproduce: 1. Make a route 2. Curl the route with a custom Proxy header 3. Sniff the traffic at the endpoint (or run an endpoint that dumps the env) Actual results: You can see that PROXY is passed as a header. Expected results: We should strip it. Additional info:
Reference https://github.com/openshift/origin/issues/14516
From the fixed PR https://github.com/openshift/origin/pull/15146, seems it did not update for passthrough route. 1. Create pod/service/passthrough route 2. Access the route with 'proxy' header curl -H 'proxy: 10.11.11.11' https://pass-z1.0723-ihz.qe.rhcloud.com -k <pre> host: pass-z1.0723-ihz.qe.rhcloud.com user-agent: curl/7.47.1 accept: */* proxy: 10.11.11.11 </pre> you can see the proxy still in the header FYI. Checked the unsecure/edge/reencrypty routes, they are work well.
A passthrough route passes encrypted traffic directly to the backend. It does not have the certs needed to decrypt the packets so it can't strip the proxy header. This is intended operation, not a bug.
@ phil Cameron Thanks for your reply and confirm. Verified this bug on oc v3.6.153
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:1716