CAPI shouldn't allow users to create apps with routes matching CF service subdomains

[djvdorp]

Today we stumbled upon a very interesting bug within CAPI, which I spoke about with @nebhale on the CloudFoundry (Open Source) Slack.

We were experiencing HTTP 404 errors approximately ~50% of the time when connecting to the UAA via the CF CLI. We also had similar errors with one of our internal services using the cf-java-client, which gave us errors such as Error requesting access token.

Turns out that one of our users has created an app with route login.ourdomain.ext, and that caused this behaviour. Since you can have multiple apps with the same domain bound on it, CF is nicely load-balancing traffic to the 'real' login.ourdomain.ext (the UAA) and the user's app, which makes this fail the ~50% of the time my CF CLI or cf-java-client hits the user's app instead of the actual UAA.
In our case, the user was not a malicious user, but it would be pretty straight forward to inject a “Yes Always” application that listens on the same route as the UAA, which would then catch/receive UAA (OAuth) tokens.

In the case of the cf-java-client (and also the CF CLI) I think it makes sense they don't block this kind of behaviour, as they will just act as a pure passthrough for anything you request. However, I believe that CF should block the ability to use the same route as the UAA though for security reasons.

In a default (stock) CF-release installation, we believe this should (probably) at least be blocked for these CF service subdomains, if this has not already been done:

• api.ourdomain.ext
• uaa.ourdomain.ext / login.ourdomain.ext
• hm9000.ourdomain.ext
• loggregator.ourdomain.ext
• doppler.ourdomain.ext

We think that this might be a CAPI (security) issue. @nebhale will also ask @jbayer about this in person.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/116208645.

[jbayer]

@djvdorp thank you for the report. we strongly advise separating the app serving domain from the system domain so that creating routes on the system domain is not enabled for non-admin users. i will talk with @nebhale @dieucao @SocalNick about this.

[fraenkel]

CAPI just added support to allow an administrator to blacklist/whitelist the private domains via the rules defined by PublicSuffix.org

[SocalNick]

@fraenkel I think we want to keep these concerns separate, the reserved private domains feature aims to block a user from creating private domains like co.uk. In this case, it's routes on a shared domain that are the problem.

[SocalNick]

The ideal solution would be to require the system_domain to not be in the list of app_domains and require a system_domain_organization. This would create a private domain in the system org.

This change would likely affect a large number of existing Cloud Foundry deployments so I will be seeking feedback on the cf-dev@cloudfoundry.org mailing list.

[SocalNick]

We will address with this story: https://www.pivotaltracker.com/story/show/117250971

Re-open if you have any other questions or concerns.