Registry v3.3.0 introduced CO-specific API users, which can be either privileged (having full access to the CO via the API) or unprivileged (having no specific access unless granted). By crafting a specific sequence of API requests, a privileged CO-specific API user can obtain escalated privileges in another CO, including the COmanage CO (and therefore obtaining platform level privileges).
The severity of this issue is medium, as a privileged API user is required to escalate privileges.
The exposure will generally be low, as this advisory only meaningfully affects multi-tenant deployments, and only those that have enabled CO-specific API users.
Deployments not using the described configuration need not take any action, though should plan an upgrade as soon as plausible in case CO-specific API users are created later.
Deployments using the described configuration should immediately upgrade to Registry v3.3.3, or to develop commit b014a9301a or later.
Deployments may also perform an audit, as described in Discussion, below.
Deployments may alternately disable any privileged CO-specific API users until an upgrade can be performed.
Registry v3.3.0 introduced CO-specific API users, which can be either privileged (having full access to the CO via the API) or unprivileged (having no specific access unless granted). Previously, the REST API was only available to platform-wide superusers.
Certain data validation routines were not correctly updated as part of this new feature, and as a result a carefully crafted series of API calls could allow a CO-specific privileged API user to create elevated access in another CO, including to a platform administrator identity. This condition does not allow an unprivileged API user to elevate to a privileged API user.
To check for exploits, SQL queries can be used to compare the
actor_identifier to the CO of the relevant record. For example:
Tables to examine include