| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can reset the password of user-accounts of Admin role type. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.
Users are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:
* Strict validation on Role Type hierarchy: the caller's user-account role must be equal to or higher than the target user-account's role.
* API privilege comparison: the caller must possess all privileges of the user they are operating on.
* Two new domain-level settings (restricted to the default Admin):
- role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: "Admin, DomainAdmin, ResourceAdmin".
- allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true. |
| When an Apache CloudStack user-account creates a CKS-based Kubernetes cluster in a project, the API key and the secret key of the 'kubeadmin' user of the caller account are used to create the secret config in the CKS-based Kubernetes cluster. A member of the project who can access the CKS-based Kubernetes cluster, can also access the API key and secret key of the 'kubeadmin' user of the CKS cluster's creator's account. An attacker who's a member of the project can exploit this to impersonate and perform privileged actions that can result in complete compromise of the confidentiality, integrity, and availability of resources owned by the creator's account.
CKS users are recommended to upgrade to version 4.19.3.0 or 4.20.1.0, which fixes this issue.Updating Existing Kubernetes Clusters in ProjectsA service account should be created for each project to provide limited access specifically for Kubernetes cluster providers and autoscaling. Follow the steps below to create a new service account, update the secret inside the cluster, and regenerate existing API and service keys:1. Create a New Service AccountCreate a new account using the role "Project Kubernetes Service Role" with the following details:
Account Name
kubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID>
First Name
Kubernetes
Last Name
Service User
Account Type
0 (Normal User)
Role ID
<ID_OF_SERVICE_ROLE>
2. Add the Service Account to the ProjectAdd this account to the project where the Kubernetes cluster(s) are hosted.
3. Generate API and Secret KeysGenerate API Key and Secret Key for the default user of this account.
4. Update the CloudStack Secret in the Kubernetes ClusterCreate a temporary file `/tmp/cloud-config` with the following data:
api-url = <API_URL> # For example: <MS_URL>/client/api
api-key = <SERVICE_USER_API_KEY>
secret-key = <SERVICE_USER_SECRET_KEY>
project-id = <PROJECT_ID>
Delete the existing secret using kubectl and Kubernetes cluster config:
./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret
Create a new secret using kubectl and Kubernetes cluster config:
./kubectl --kubeconfig kube.conf -n kube-system create secret generic cloudstack-secret --from-file=/tmp/cloud-config
Remove the temporary file:
rm /tmp/cloud-config5. Regenerate API and Secret KeysRegenerate the API and secret keys for the original user account that was used to create the Kubernetes cluster. |
| CloudStack users can add and read comments (annotations) on resources they are authorised to access.
Due to an access validation issue that affects Apache CloudStack versions from 4.16.0, users who have access, prior access or knowledge of resource UUIDs can list and add comments (annotations) to such resources.
An attacker with a user-account and access or prior knowledge of resource UUIDs may exploit this issue to read contents of the comments (annotations) or add malicious comments (annotations) to such resources.
This may cause potential loss of confidentiality of CloudStack environments and resources if the comments (annotations) contain any privileged information. However, guessing or brute-forcing resource UUIDs are generally hard to impossible and access to listing or adding comments isn't same as access to CloudStack resources, making this issue of very low severity and general low impact.
CloudStack admins may also disallow listAnnotations and addAnnotation API access to non-admin roles in their environment as an interim measure. |
| A problem has been identified in the CloudStack additional VM configuration (extraconfig) feature which can be misused by anyone who has privilege to deploy a VM instance or configure settings of an already deployed VM instance, to configure additional VM configuration even when the feature is not explicitly enabled by the administrator. In a KVM based CloudStack environment, an attacker can exploit this issue to attach host devices such as storage disks, and PCI and USB devices such as network adapters and GPUs, in a regular VM instance that can be further exploited to gain access to the underlying network and storage infrastructure resources, and access any VM instance disks on the local storage.
Users are advised to upgrade to version 4.18.1.1 or 4.19.0.1, which fixes this issue.
|
| The CloudStack Quota plugin has an improper privilege management logic in version 4.20.0.0. Anyone with authenticated user-account access in CloudStack 4.20.0.0 environments, where this plugin is enabled and have access to specific APIs can enable or disable reception of quota-related emails for any account in the environment and list their configurations.
Quota plugin users using CloudStack 4.20.0.0 are recommended to upgrade to CloudStack version 4.20.1.0, which fixes this issue. |
| Apache CloudStack 4.0.0 before 4.0.2 and Citrix CloudPlatform (formerly Citrix CloudStack) 3.0.x before 3.0.6 Patch C uses a hash of a predictable sequence, which makes it easier for remote attackers to guess the console access URL via a brute force attack. |
| Apache CloudStack 4.0.0 before 4.0.2 and Citrix CloudPlatform (formerly Citrix CloudStack) 3.0.x before 3.0.6 Patch C allows remote attackers to bypass the console proxy authentication by leveraging knowledge of the source code. |
| Apache CloudStack before 4.3.2 and 4.4.x before 4.4.2 allows remote attackers to obtain private keys via a listSslCerts API call. |
| Apache CloudStack before 4.5.2 does not properly preserve VNC passwords when migrating KVM virtual machines, which allows remote attackers to gain access by connecting to the VNC server. |
| Apache CloudStack 4.5.x before 4.5.2.1, 4.6.x before 4.6.2.1, 4.7.x before 4.7.1.1, and 4.8.x before 4.8.0.1, when SAML-based authentication is enabled and used, allow remote attackers to bypass authentication and access the user interface via vectors related to the SAML plugin. |
| Apache CloudStack 4.3.x before 4.3.2 and 4.4.x before 4.4.2 allows remote attackers to bypass authentication via a login request without a password, which triggers an unauthenticated bind. |
| Apache CloudStack before 4.5.2 might allow remote authenticated administrators to obtain sensitive password information for root accounts of virtual machines via unspecified vectors related to API calls. |
| Citrix Cloud.com CloudStack, and Apache CloudStack pre-release, allows remote attackers to make arbitrary API calls by leveraging the system user account, as demonstrated by API calls to delete VMs. |
| Apache CloudStack 4.0.0-incubating and Citrix CloudPlatform (formerly Citrix CloudStack) before 3.0.6 stores sensitive information in the log4j.conf log file, which allows local users to obtain (1) the SSH private key as recorded by the createSSHKeyPair API, (2) the password of an added host as recorded by the AddHost API, or the password of an added VM as recorded by the (3) DeployVM or (4) ResetPasswordForVM API. |
| Multiple cross-site scripting (XSS) vulnerabilities in Apache CloudStack before 4.1.1 allow remote attackers to inject arbitrary web script or HTML via the (1) Physical network name to the Zone wizard; (2) New network name, (3) instance name, or (4) group to the Instance wizard; (5) unspecified "multi-edit fields;" and (6) unspecified "list view" edit fields related to global settings. |
| The virtual router in Apache CloudStack before 4.2.1 does not preserve the source restrictions in firewall rules after being restarted, which allows remote attackers to bypass intended restrictions via a request. |
| The (1) ListNetworkACL and (2) listNetworkACLLists APIs in Apache CloudStack before 4.2.1 allow remote authenticated users to list network ACLS for other users via a crafted request. |
| By default the CloudStack management server honours the x-forwarded-for HTTP header and logs it as the source IP of an API request. This could lead to authentication bypass and other operational problems should an attacker decide to spoof their IP address this way. Users are recommended to upgrade to CloudStack version 4.18.1.1 or 4.19.0.1, which fixes this issue.
|
| The CloudStack SAML authentication (disabled by default) does not enforce signature check. In CloudStack environments where SAML authentication is enabled, an attacker that initiates CloudStack SAML single sign-on authentication can bypass SAML authentication by submitting a spoofed SAML response with no signature and known or guessed username and other user details of a SAML-enabled CloudStack user-account. In such environments, this can result in a complete compromise of the resources owned and/or accessible by a SAML enabled user-account.
Affected users are recommended to disable the SAML authentication plugin by setting the "saml2.enabled" global setting to "false", or upgrade to version 4.18.2.2, 4.19.1.0 or later, which addresses this issue. |
| The CloudStack integration API service allows running its unauthenticated API server (usually on port 8096 when configured and enabled via integration.api.port global setting) for internal portal integrations and for testing purposes. By default, the integration API service port is disabled and is considered disabled when integration.api.port is set to 0 or negative. Due to an improper initialisation logic, the integration API service would listen on a random port when its port value is set to 0 (default value). An attacker that can access the CloudStack management network could scan and find the randomised integration API service port and exploit it to perform unauthorised administrative actions and perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.
Users are recommended to restrict the network access on the CloudStack management server hosts to only essential ports. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue. |
