Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificates and accounts associated with tenanted deployment targets are not validated #6530

Closed
tothegills opened this issue Aug 23, 2020 · 0 comments
Assignees
Labels
area/security kind/bug This issue represents a verified problem we are committed to solving priority (obsolete) This issue has been recognised as a priority and should be addressed as soon as possible release/2020.2 tag/breaking-change The resolution of this issue introduced a deliberately breaking change
Milestone

Comments

@tothegills
Copy link
Contributor

tothegills commented Aug 23, 2020

This is the 2020.2.18 version of #6529

CVE-2020-16197

Description

A credential scoped to one tenant could be used to affect another tenant in certain circumstances.

Effectively, the logic was previously, "A credential may be used to access this target if it is applicable to any tenant on this target", and has been changed to, "A credential may be used to access this target only if it is applicable to ALL tenants on this target."

For example, given a certificate scoped to Tenant A and a deployment target scoped to Tenant A and Tenant B, the certificate would have previously been permitted to be used by the deployment. To give a more concrete example: with a Kubernetes cluster containing two tenants' application instances, changes made to the cluster can conceivably affect both tenants, so the certificate used to authenticate to the cluster now needs to be scoped to both tenants in order for its use to be permitted.

Affected versions

Octopus Server: 3.4 (since tenants were introduced).

Mitigation / Fix

  1. If an account/certificate is marked as "Exclude from tenanted deployments", change it to "Include in both tenanted and untenanted deployments".
  2. Add any missing tenants to the account/certificate.

In some edge cases, it is possible that an account or certificate has been inadvertently reused across tenants where it genuinely should not have been shared.

In this case, we recommend that you:

  • Provision a new account/certificate for each tenant whose infrastructure is completely segregated from the others.
  • Scope the new account/certificate to just that tenant.

In the second scenario, it is feasible as a short-term workaround to follow the same steps as in the first scenario (i.e. scope the credential to all the tenants to mimic previous behavior) until the additional accounts/certificates have been provisioned.

Links

@tothegills tothegills added kind/bug This issue represents a verified problem we are committed to solving priority (obsolete) This issue has been recognised as a priority and should be addressed as soon as possible area/security release/2020.2 labels Aug 23, 2020
@tothegills tothegills added this to the 2020.2.18 milestone Aug 23, 2020
@tothegills tothegills self-assigned this Aug 23, 2020
@zentron zentron added the tag/breaking-change The resolution of this issue introduced a deliberately breaking change label Jan 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/security kind/bug This issue represents a verified problem we are committed to solving priority (obsolete) This issue has been recognised as a priority and should be addressed as soon as possible release/2020.2 tag/breaking-change The resolution of this issue introduced a deliberately breaking change
Projects
None yet
Development

No branches or pull requests

2 participants