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

Potential Azure account scoping bypass #4134

Closed
slewis74 opened this issue Jan 3, 2018 · 2 comments
Closed

Potential Azure account scoping bypass #4134

slewis74 opened this issue Jan 3, 2018 · 2 comments
Assignees
Milestone

Comments

@slewis74
Copy link

slewis74 commented Jan 3, 2018

CVE-2018-4862

An authenticated user with ProcessEdit permission could reference an Azure account in such a way as to bypass the environment restrictions.

Relates to OctopusDeploy/OctopusDeploy#1711

Octopus Account restrictions explained

Azure Accounts can be configured so it's available for use in any deployment. This is typical when you use the same Azure Subscription for everything. However, when you have multiple Azure Subscriptions you want to deploy to you need one Azure Account per subscription.

You might be happy to leave the Azure Accounts unrestricted and just resolve the correct account at deployment time using a variable binding. Otherwise you might decide to restrict each Azure Account so it can only be used for deployments targeting specific Environments or even for certain Tenants.

Octopus will actively prevent deployments that don't match the Azure Account's restrictions from using the Azure Account. This is useful when you want to actively prevent a deployment bound for your Test Environment / Test Azure Subscription from being deployed to your Production Azure Subscription.

Vulnerability

An authenticated user with the ProcessEdit permission could craft their deployment process in a very specific way to reference an Account (Azure Accounts, Username Password Accounts, SSH Key Accounts) which would prevent Octopus from checking the restrictions correctly. Thus that authenticated user could use a restricted Account in the wrong context by accident or with malicious intent.

If you don't use Accounts you are not vulnerable.
If you use Accounts without any restrictions you are not vulnerable.

Affected versions

Octopus Deploy 3.2.11 to 4.1.5.

Mitigation

Upgrade to Octopus 4.1.6.

@slewis74 slewis74 added this to the 4.1.6 milestone Jan 3, 2018
@slewis74 slewis74 closed this as completed Jan 3, 2018
@octoreleasebot
Copy link

octoreleasebot commented Jan 3, 2018

Release Note: Fixed potential scoping bypass when referencing Azure accounts

@lock
Copy link

lock bot commented Nov 23, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. If you think you've found a related issue, please contact our support team so we can triage your issue, and make sure it's handled appropriately.

@lock lock bot locked as resolved and limited conversation to collaborators Nov 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants