Apache Pulsar namespaces can restrict which roles may use a subscription, either with the Prefix subscription authentication mode, which requires a subscription name to start with the role name, or by granting permission on a subscription to specific roles. Topic-level subscription operations, such as consuming, skipping messages, resetting a cursor or deleting a subscription, apply these subscription policies. Several admin REST API operations that act on subscriptions did not apply them:
- the namespace-level and bundle-level clear backlog operations, both for a named subscription and for all subscriptions;
- the namespace-level and bundle-level unsubscribe operations;
- the topic-level operation that expires messages for all subscriptions of a topic.
With the default authorization provider, the namespace-level operations require only consume permission granted on the namespace, and the expire-all operation requires only consume permission on the topic. As a result, when authentication and authorization are enabled and a namespace uses the Prefix subscription authentication mode or subscription permissions, an authenticated user with such consume permission can clear the backlog of, expire messages of, or delete a subscription that the policies would deny to that user. Tenant admin or superuser access is not required. The clear backlog operations can also be applied to the cursors used for geo-replication, so that messages not yet replicated to a remote cluster are skipped. Deployments that do not configure the Prefix subscription authentication mode or subscription permissions (the defaults) are not affected by this bypass, because consume permission on the namespace or topic already allows these operations there. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different.
The impact is on the integrity of subscription state. Clearing or expiring the backlog moves the subscriptions cursor forward, so unacknowledged messages are no longer delivered to the subscriptions consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespaces retention policy keeps them. The issue does not allow reading message contents, changing permissions or policies, or accessing other namespaces, and it does not affect the availability of the broker.
In fixed versions, the namespace-level and bundle-level operations for a named subscription apply the subscription policies to that subscription, and the operations for all subscriptions, when requested by a user who is not a tenant admin or superuser, only act on the subscriptions that the user may access. Clearing the backlog of geo-replication cursors requires tenant admin or superuser access. Topic-level subscription operations apply the subscription policies for all types of authentication data, including that of the anonymous user role.
This issue affects Apache Pulsar versions from 2.8.0 before 4.0.14 and from 4.1.0 before 4.2.5.
- 4.0.x version users should upgrade to at least 4.0.14.
- 4.1.x and 4.2.x version users should upgrade to at least 4.2.5.
All brokers in a cluster must be upgraded before relying on the namespace-level restrictions, because brokers that have not been upgraded do not apply them when they receive the internal per-bundle requests.
Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.
The currently supported Apache Pulsar release lines are 4.0.x and 5.0.x. The supported versions schedule is available at https://pulsar.apache.org/contribute/release-policy/.
Users who cannot upgrade immediately can reduce exposure by restricting network access to the brokers admin REST API to trusted administrative clients.
Weakness
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
Potential Mitigations
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.