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.
The text was updated successfully, but these errors were encountered:
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.
lockbot
locked as resolved and limited conversation to collaborators
Nov 23, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
2 participants
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.
CVE-2018-4862An authenticated user with
ProcessEditpermission 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
ProcessEditpermission 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.11to4.1.5.Mitigation
Upgrade to Octopus
4.1.6.The text was updated successfully, but these errors were encountered: