Описание
In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.
A flaw was found in OpenStack Designate. When the AttributeFilter scheduler is enabled with multiple DNS pools, an authenticated tenant can bypass zone ownership checks by scheduling a zone to a different pool. The database uniqueness constraint on zone names is pool-scoped, and the subzone/superzone ownership checks in the Central service include pool_id in their query criteria, making them pool-scoped rather than global. This allows a tenant to create zones that overlap with another tenant's zones in a different pool, bypassing cross-tenant namespace isolation. Successful exploitation could lead to cross-tenant DNS zone overlap and subzone ownership bypass.
Отчет
Red Hat OpenStack Platform (RHOSP) ships Designate across multiple versions. Multipool deployments using the AttributeFilter scheduler were never a fully supported configuration in any RHOSP version. In RHOSP 13, 16.2, and 17.1 (TripleO deployment), the default scheduler_filters configuration is default_pool, which assigns all zones to a single pool and prevents the cross-tenant zone overlap. For Red Hat OpenStack Services on OpenShift (RHOSO, openstack-18.0), the designate-operator hardcodes scheduler_filters to pool_id_attribute, in_doubt_default_pool in the central service configuration template. The pool_id_attribute filter enforces the zone_create_forced_pool policy check, which defaults to requiring the SYSTEM_ADMIN role, preventing regular tenants from selecting pools. Therefore, RHOSO is not affected in the default configuration. However, RHOSO becomes affected if an administrator uses the customServiceConfig field to set scheduler_filters to include the attribute filter, as customServiceConfig is a freeform string with no CRD validation or webhook filtering, written to a config-dir override that oslo.config loads with last-wins semantics, silently overriding the operator's safe default.
Меры по смягчению последствий
For deployments not using multi-pool DNS: verify that the 'scheduler_filters' configuration option in the [service:central] section only contains 'default_pool' (the default value). This prevents tenants from selecting alternative pools and eliminates the zone overlap vulnerability. For deployments using multi-pool DNS: replace the 'attribute' filter with 'pool_id_attribute' in the 'scheduler_filters' configuration. The pool_id_attribute filter enforces the 'zone_create_forced_pool' policy check, which defaults to requiring the SYSTEM_ADMIN role, preventing regular tenants from choosing pools.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat OpenStack Platform 13 (Queens) | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 17.1 | openstack-designate | Fix deferred | ||
| Red Hat OpenStack Platform 18.0 | openstack-designate | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
4.3 Medium
CVSS3
Связанные уязвимости
In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.
In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.
In OpenStack Designate before 22.0.1, zone creation checks (_is_subzon ...
In OpenStack Designate before 22.0.1, zone creation checks (_is_subzone, _is_superzone, and the duplicate-zone DB constraint) are scoped to the target pool only. An authenticated user can bypass these checks by scheduling a zone to a different pool via the AttributeFilter scheduler, creating an overlapping zone that conflicts with another tenant's zone. This enables cross-tenant DNS hijack (redirecting traffic to attacker-controlled IPs) and DNS denial of service (NODATA responses). Exploitation requires a multi-pool deployment with AttributeFilter enabled in scheduler_filters, which is a non-default but documented and supported configuration for self-service tiering.
EPSS
4.3 Medium
CVSS3