haproxy obfuscated internal IP in routing cookie #8334

pecameron · 2016-04-01T19:43:10Z

The cookie currently returns the openshift internal pod IP address.
This is a security issue as an attacker can develop a map of the pods
in the cluster just by observing the returned cookie.

This change returns a hash of the internal address and internal service
name to obfuscate the internal information. The service name is configured
when the service is created and is not visible to outside users. This
in combination with the internal ip:port is hashed and presented in the
cookie.

addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1318796

knobunc · 2016-04-04T12:32:07Z

pkg/router/template/router.go

 		return svc.EndpointTable
 	}
 	endpoints := make([]Endpoint, 0, len(svc.EndpointTable))
 	for i := range svc.EndpointTable {
 		endpoint := svc.EndpointTable[i]
 		if endpoint.PortName == alias.PreferPort || endpoint.Port == alias.PreferPort {
+			s := endpoint.ID+endpoint.TargetName+endpoint.PortName
+			endpoint.IDhash = fmt.Sprintf("%x", md5.Sum([]byte(s)))


Why is this inconsistent with the call a few lines above. I'd lose hash above.

eparis · 2016-04-04T14:35:56Z

pkg/router/template/router.go

@@ -172,12 +173,20 @@ func newTemplateRouter(cfg templateRouterCfg) (*templateRouter, error) {

 func endpointsForAlias(alias ServiceAliasConfig, svc ServiceUnit) []Endpoint {
 	if len(alias.PreferPort) == 0 {
+		for i := range svc.EndpointTable {
+			endpoint := svc.EndpointTable[i]


Assuming this is necessary (it's weird to me you are walking this table twice, but I haven't actually looked at it) I think the idiomatic go way to update the values stored in items in a slice would be:

for i := range svc.EndpointTable { endpoint := &svc.EndpointTable[i] hash := $WHATEVER endpoint.IDHash = fmt.Sprintf(....hash) }

Notice endpoint is a pointer to the value.

Now if I were going to write it your way, because I didn't really understand or want to use pointers but did want to make use of the return values of range it should look like:

for i, endpoint := range svc.EndpointTable { hash := $WHATEVER svc.EndpointTable[i].IDhash = fmt.Sprintf("%x", hash) }

knobunc · 2016-04-04T17:54:31Z

pkg/router/template/router.go

 	if len(alias.PreferPort) == 0 {
+		for i := range svc.EndpointTable {
+			endpoint := svc.EndpointTable[i]


I think you missed @eparis' comment about the go idioms.

It's ugly that we have to do the same thing in two places though. Perhaps make a private function that computes a hash value from an Endpoints structure?

Didn't miss it, misunderstood it. I will make a private function as you
suggest.
On 04/04/2016 01:54 PM, Ben Bennett wrote:

In pkg/router/template/router.go
#8334 (comment):

if len(alias.PreferPort) == 0 {

for i := range svc.EndpointTable {

endpoint := svc.EndpointTable[i]

I think you missed @eparis https://github.com/eparis' comment about
the go idioms.

It's ugly that we have to do the same thing in two places though.
Perhaps make a private function that computes a hash value from an
Endpoints structure?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/pull/8334/files/d5a28c792427c49fed6676cc043d4a13b621d62c#r58417984

Better to do this when we add an endpoint - see: https://github.com/pecameron/origin/blob/bz1318796/pkg/router/template/router.go#L507 rather than in here endpointsForAlias.

Reason is endpointsForAlias is called every time we handle the template (router config) and there would be multiple calls in the lifetime of a router (as endpoints/routes get added/removed/modified). It's not performant to calculate the IDHash for all the endpoints on every single call to endpointsForAlias.
Just do it once when we add the endpoint.

That way, you can also inline the function as it will be only used in a single place.

knobunc · 2016-04-05T13:05:01Z

This looks much better. LGTM.

ramr · 2016-04-05T18:22:29Z

Code LGTM - If you could also add to the AddEndpoints test here: https://github.com/ramr/origin/blob/master/pkg/router/template/router_test.go#L68
just check that the actualEp.IdHash is set and matches expectations.

ramr · 2016-04-05T21:08:17Z

As discussed over email - testing that the IdHash is valid looks fine but as re: the test failures for:

--- FAIL: TestAddEndpointDuplicates (0.00s)  
    router_test.go:123: add same endpoints expected to return false but got true  
W0405 15:21:34.318716   26055 router.go:696] a edge terminated route with host edgetermfalse does   not have the required certificates. The route will still be created but no certificates will be written  
W0405 15:21:34.319183   26055 router.go:696] a reencrypt terminated route with host  reencrypttermfalse does not have the required certificates.  The route will still be created but no   certificates will be written  
FAIL

There is a check above the added code to ensure that if we add the same endpoints, we don't reload the router (return false from here basically since the config is unchanged). But since we now set the IdHash below this check, the 2 objects will never match up. So better to just move setting the IdHash to plugin.go#createRouterEndpoints.

pecameron · 2016-04-07T15:08:46Z

Above failure seems to be a flake:

I0406 16:14:51.933815 23883 client.go:320] Found registry v2 API at https://registry-1.docker.io/v2/
--- FAIL: TestRegistryClientImageV2-2 (0.12s)
dockerregistryclient_test.go:206: tag "latest" has not been set on repository "openshift/origin"
FAIL

knobunc · 2016-04-08T17:39:17Z

[test]

pecameron · 2016-04-11T20:35:58Z

[FLAKE:8466] problem is not in networking.

eparis · 2016-04-12T17:03:14Z

[test]

eparis · 2016-04-12T18:10:44Z

[merge] because looks like the last failure is #8480

pecameron · 2016-04-18T14:17:25Z

[TEST]

eparis · 2016-04-18T14:20:24Z

looks like you messed up the rebase quite badly...

pecameron · 2016-04-18T14:21:17Z

eparis, help! I sent you email

The cookie currently returns the openshift internal pod IP address. This is a security issue as an attacker can develop a map of the pods in the cluster just by observing the returned cookie. This change returns a hash of the internal address and internal service name to obfuscate the internal information. The service name is configured when the service is created and is not visible to outside users. This in combination with the internal ip:port is hashed and presented in the cookie. addresses: https://bugzilla.redhat.com/show_bug.cgi?id=1318796

eparis · 2016-04-18T15:14:34Z

approved and [merge] failed test looks unrelated.

openshift-bot · 2016-04-18T15:15:22Z

Evaluated for origin test up to 36c680b

eparis · 2016-04-18T17:43:00Z

[merge] again because the failure is unrelated crap.

pecameron · 2016-04-19T13:20:04Z

@eparis Still failing. Could you try the merge again?

eparis · 2016-04-19T13:25:16Z

[merge] with extreme prejudice

eparis · 2016-04-19T13:47:22Z

This is [merge] try number 5
@danmcp I'm guessing there is nothing we can do about the aws m4.large failures?

danmcp · 2016-04-19T14:13:41Z

@eparis We have done some stuff. Most of the tests are no longer using them (they didn't really need them anyway). We can also switch zones if it continues to be a problem. I need to (or someone does) to do a little research to pick the best one to move to if we are going to switch.

openshift-bot · 2016-04-19T19:45:19Z

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5637/) (Image: devenv-rhel7_3997)

openshift-bot · 2016-04-19T20:25:21Z

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/3106/)

eparis · 2016-04-19T20:26:50Z

[merge] you silly PR. merge!

openshift-bot · 2016-04-19T20:30:25Z

Evaluated for origin merge up to 36c680b

knobunc reviewed Apr 4, 2016
View reviewed changes

pecameron force-pushed the bz1318796 branch 2 times, most recently from 1be8c21 to 3e5d176 Compare April 4, 2016 13:30

eparis reviewed Apr 4, 2016
View reviewed changes

pecameron force-pushed the bz1318796 branch from 3e5d176 to d5a28c7 Compare April 4, 2016 15:19

knobunc reviewed Apr 4, 2016
View reviewed changes

pecameron force-pushed the bz1318796 branch from d5a28c7 to 58aca5b Compare April 4, 2016 20:21

pecameron force-pushed the bz1318796 branch from 58aca5b to c78ed19 Compare April 6, 2016 19:02

pecameron force-pushed the bz1318796 branch from f2431e3 to 36c680b Compare April 18, 2016 14:37

openshift-bot merged commit 2d4cec7 into openshift:master Apr 19, 2016

pecameron deleted the bz1318796 branch April 20, 2016 14:46

tatianab mentioned this pull request Nov 8, 2023

x/vulndb: potential Go vuln in github.com/openshift/origin: CVE-2016-3711 golang/vulndb#2192

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

haproxy obfuscated internal IP in routing cookie #8334

haproxy obfuscated internal IP in routing cookie #8334

pecameron commented Apr 1, 2016

knobunc Apr 4, 2016

eparis Apr 4, 2016

knobunc Apr 4, 2016

pecameron Apr 4, 2016

ramr Apr 4, 2016

knobunc commented Apr 5, 2016

ramr commented Apr 5, 2016

ramr commented Apr 5, 2016

pecameron commented Apr 7, 2016

knobunc commented Apr 8, 2016

pecameron commented Apr 11, 2016

eparis commented Apr 12, 2016

eparis commented Apr 12, 2016

pecameron commented Apr 18, 2016

eparis commented Apr 18, 2016

pecameron commented Apr 18, 2016

eparis commented Apr 18, 2016

openshift-bot commented Apr 18, 2016

eparis commented Apr 18, 2016

pecameron commented Apr 19, 2016

eparis commented Apr 19, 2016

eparis commented Apr 19, 2016

danmcp commented Apr 19, 2016

openshift-bot commented Apr 19, 2016

openshift-bot commented Apr 19, 2016

eparis commented Apr 19, 2016

openshift-bot commented Apr 19, 2016

haproxy obfuscated internal IP in routing cookie #8334

haproxy obfuscated internal IP in routing cookie #8334

Conversation

pecameron commented Apr 1, 2016

knobunc Apr 4, 2016

Choose a reason for hiding this comment

eparis Apr 4, 2016

Choose a reason for hiding this comment

knobunc Apr 4, 2016

Choose a reason for hiding this comment

pecameron Apr 4, 2016

Choose a reason for hiding this comment

ramr Apr 4, 2016

Choose a reason for hiding this comment

knobunc commented Apr 5, 2016

ramr commented Apr 5, 2016

ramr commented Apr 5, 2016

pecameron commented Apr 7, 2016

knobunc commented Apr 8, 2016

pecameron commented Apr 11, 2016

eparis commented Apr 12, 2016

eparis commented Apr 12, 2016

pecameron commented Apr 18, 2016

eparis commented Apr 18, 2016

pecameron commented Apr 18, 2016

eparis commented Apr 18, 2016

openshift-bot commented Apr 18, 2016

eparis commented Apr 18, 2016

pecameron commented Apr 19, 2016

eparis commented Apr 19, 2016

eparis commented Apr 19, 2016

danmcp commented Apr 19, 2016

openshift-bot commented Apr 19, 2016

openshift-bot commented Apr 19, 2016

eparis commented Apr 19, 2016

openshift-bot commented Apr 19, 2016