Summary
Rucio's /credentials/signurl endpoint uses the caller-supplied X-Rucio-Account header for a permission check instead of the account established by token authentication. An authenticated low-privilege user may be able to obtain presigned URLs for cloud-backed objects, potentially enabling data access or changes beyond their authorized scope.
Rucio's /credentials/signurl endpoint uses the caller-supplied X-Rucio-Account header for a permission check instead of the account established by token authentication. An authenticated low-privilege user may be able to obtain presigned URLs for cloud-backed objects, potentially enabling data access or changes beyond their authorized scope.
Affected context
The issue affects Rucio deployments with the /credentials/signurl endpoint when it relies on X-Rucio-Account rather than the authenticated issuer for authorization. The risk is particularly relevant where the endpoint can use stored S3, GCS, or Swift credentials to create URLs for reading, writing, or deleting objects. In multi-VO deployments, the X-Rucio-VO header may also affect tenant selection.
The issue affects Rucio deployments with the /credentials/signurl endpoint when it relies on X-Rucio-Account rather than the authenticated issuer for authorization. The risk is particularly relevant where the endpoint can use stored S3, GCS, or Swift credentials to create URLs for reading, writing, or deleting objects. In multi-VO deployments, the X-Rucio-VO header may also affect tenant selection.
Exploit preconditions
- Attack surface: The Rucio
/credentials/signurlendpoint - Required access: An authenticated account; the described issue does not require the caller to already have root privileges
- Trigger point: Authorization when requesting a presigned URL for an object
- Why exploitation is possible: The permission check trusts the caller-controlled
X-Rucio-Accountvalue instead of the authenticated issuer, allowing a low-privilege caller to presentrootfor the root-only permission check - Additional context: Cloud-backed RSE credentials and, for cross-tenant exposure, a multi-VO deployment may increase the potential scope
- Attack surface: The Rucio
/credentials/signurlendpoint - Required access: An authenticated account; the described issue does not require the caller to already have root privileges
- Trigger point: Authorization when requesting a presigned URL for an object
- Why exploitation is possible: The permission check trusts the caller-controlled
X-Rucio-Accountvalue instead of the authenticated issuer, allowing a low-privilege caller to presentrootfor the root-only permission check - Additional context: Cloud-backed RSE credentials and, for cross-tenant exposure, a multi-VO deployment may increase the potential scope
Why this happens
The endpoint makes an authorization decision using an identity supplied in a request header rather than the identity established by token authentication. This is an authorization bypass through a user-controlled key, mapping to CWE-639. Authorization checks should use a trusted, server-established principal and should consistently bind requested resources and tenant context to that principal.
The endpoint makes an authorization decision using an identity supplied in a request header rather than the identity established by token authentication. This is an authorization bypass through a user-controlled key, mapping to CWE-639. Authorization checks should use a trusted, server-established principal and should consistently bind requested resources and tenant context to that principal.
Potential impact
- An attacker may obtain presigned read URLs and disclose data.
- An attacker could obtain write or delete URLs and modify or remove objects.
- Cloud-backed storage access may extend beyond the caller's intended permissions.
- In multi-VO deployments, requests could enable unauthorized cross-tenant access.
- An attacker may obtain presigned read URLs and disclose data.
- An attacker could obtain write or delete URLs and modify or remove objects.
- Cloud-backed storage access may extend beyond the caller's intended permissions.
- In multi-VO deployments, requests could enable unauthorized cross-tenant access.
General mitigation guidance
Defensive patterns include:
- Derive authorization identity from the authenticated server-side principal, not caller-controlled identity headers.
- Enforce authorization for each requested operation and object using trusted identity and tenant context.
- Treat account and VO headers as untrusted input; validate them against the authenticated principal and explicit delegation rules.
- Apply least privilege to cloud credentials and limit their scope, permitted operations, and lifetime.
- Avoid exposing presigned URLs with broader access or validity than the operation requires.
Defensive patterns include:
- Derive authorization identity from the authenticated server-side principal, not caller-controlled identity headers.
- Enforce authorization for each requested operation and object using trusted identity and tenant context.
- Treat account and VO headers as untrusted input; validate them against the authenticated principal and explicit delegation rules.
- Apply least privilege to cloud credentials and limit their scope, permitted operations, and lifetime.
- Avoid exposing presigned URLs with broader access or validity than the operation requires.
How teams detect issues like this
- Review endpoint code for permission checks that use request headers or other client-supplied identity values instead of the authenticated issuer.
- Use static analysis and code review checks to flag authorization decisions based on untrusted identity or tenant fields.
- Test that changing account or VO headers cannot elevate access or bypass object-level authorization.
- Monitor sign-URL requests for mismatches between authenticated identity, requested account, tenant, object, and operation.
- Enforce policies requiring server-established identities for authorization decisions.
- Review endpoint code for permission checks that use request headers or other client-supplied identity values instead of the authenticated issuer.
- Use static analysis and code review checks to flag authorization decisions based on untrusted identity or tenant fields.
- Test that changing account or VO headers cannot elevate access or bypass object-level authorization.
- Monitor sign-URL requests for mismatches between authenticated identity, requested account, tenant, object, and operation.
- Enforce policies requiring server-established identities for authorization decisions.
