Описание
In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An
attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.
A flaw was found in the S3API middleware of OpenStack Swift. When configured with s3_acl=true (non-default), Swift-native control headers such as X-Copy-From and X-Copy-From-Account are not sanitized from S3 API requests. Because the S3 ACL mode bypasses Swift's native authorization, an authenticated attacker can inject these headers to read objects from other tenants' storage. The attacker needs prior knowledge of the target project_id, container name, and object name.
Отчет
Red Hat OpenStack Platform (RHOSP) and Red Hat OpenStack Services on OpenShift (RHOSO) ship openstack-swift. This vulnerability requires the non-default s3_acl=true configuration, which the upstream documentation explicitly warns is experimental ('DON'T USE THIS for production before enough testing'). In default RHOSO deployments, s3_acl is not set, defaulting to false. Swift's native Keystone authorization properly denies cross-tenant access in this configuration. Deployments using the default s3_acl=false configuration are not affected. Only deployments that have explicitly set s3_acl=true in the [filter:s3api] section of proxy-server.conf are vulnerable.
Меры по смягчению последствий
Ensure the s3_acl configuration option is set to false (the default) in the [filter:s3api] section of proxy-server.conf. This completely mitigates the vulnerability because Swift's native authorization (Keystone/tempauth) will properly deny cross-tenant access attempts. If s3_acl=true is required and cannot be changed, restrict S3 API access to trusted networks or remove the s3api filter from the proxy-server pipeline until the patch is applied.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat OpenStack Platform 13 (Queens) | rhosp13/openstack-swift-account | Fix deferred | ||
| Red Hat OpenStack Platform 13 (Queens) | rhosp13/openstack-swift-base | Fix deferred | ||
| Red Hat OpenStack Platform 13 (Queens) | rhosp13/openstack-swift-container | Fix deferred | ||
| Red Hat OpenStack Platform 13 (Queens) | rhosp13/openstack-swift-object | Fix deferred | ||
| Red Hat OpenStack Platform 13 (Queens) | rhosp13/openstack-swift-proxy-server | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | openstack-swift | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | rhosp-rhel8/openstack-swift-account | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | rhosp-rhel8/openstack-swift-base | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | rhosp-rhel8/openstack-swift-container | Fix deferred | ||
| Red Hat OpenStack Platform 16.2 | rhosp-rhel8/openstack-swift-object | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
6.5 Medium
CVSS3
Связанные уязвимости
In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.
In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.
In OpenStack Swift through 2.38.0, the S3API middleware does not sanit ...
In OpenStack Swift through 2.38.0, the S3API middleware does not sanitize Swift-native control headers (X-Copy-From, X-Copy-From-Account) from S3 API requests when s3_acl=true. An attacker can inject these headers into a signed PUT request targeting their own bucket, causing Swift to perform a server-side copy from another tenant's private object. The source object authorization is bypassed because the S3API middleware has already authorized the request against the destination. The attacker can read any object whose project_id, container name, and object name are known, regardless of the source object's ACLs or ownership. This requires the non-default s3_acl=true configuration.
EPSS
6.5 Medium
CVSS3