Omar Mousa

The Pulsar Functions Worker provides a REST API endpoint for triggering a function, which publishes a caller-supplied value to one of the function's configured input topics. The Functions Worker performs this publish with its own broker client, which authenticates with the Worker's configured broker-client credentials rather than the credentials of the API caller. When authorization is enabled, in Apache Pulsar 2.4.0 and later versions, the trigger endpoint checks only that the caller is authorized to perform function operations in the function's namespace. It does not check that the caller is authorized to produce to the input topic that the message is published to. Versions before 2.4.0 do not perform a caller authorization check for the trigger endpoint at all. Function input topics are not restricted to the function's own tenant or namespace, and registering a function does not require produce permission on its input topics. As a result, an authenticated user who is authorized to manage functions in a namespace, for example a role granted the functions permission on that namespace, can cause the Functions Worker to publish messages with caller-controlled content to a topic that the user is not authorized to produce to, including topics in other tenants. These messages are published under the identity of the Functions Worker. The issue does not require any function instance to be running or any function code to be executed. It requires that the Functions Worker's broker-client identity is itself authorized to produce to the target topic and, in Apache Pulsar 2.3.0 and later versions, to list the subscriptions of the target topic, as is the case when that identity is a superuser. The impact is on the integrity of the data in the affected topics: consumers of those topics may receive messages from a user who is not permitted to publish them. This concerns the Functions Worker REST API as called by an external, authenticated client; it does not change the security model for function code, which must be fully trusted. In fixed versions, when authorization is enabled, triggering a function additionally requires the caller to be authorized to produce to the selected input topic before any message is published. This issue affects Apache Pulsar versions from 2.0.0-rc1-incubating 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. 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 of Apache Pulsar 2.4.0 and later versions with authorization enabled who cannot upgrade immediately can limit the permission to manage functions to trusted roles. Users of versions before 2.4.0 should restrict access to the Functions Worker REST API to trusted callers, because in these versions the trigger endpoint does not check the caller's permission to manage functions.

Apache Pulsar shadow topics (PIP-180) are topics that read the stored messages of a source topic from that topic's managed ledger. The source topic is selected by setting the reserved topic property PULSAR.SHADOW SOURCE. The admin REST API accepts this property when creating a non-partitioned or partitioned topic and when updating the properties of an existing topic. On these paths the broker authorizes the caller only against the topic being created or updated. It does not authorize the caller against the source topic named in the property. The existing authorization for shadow topic configuration (the SHADOW TOPIC topic policy on the source topic) is applied only to the source-side shadow topics admin API, not to these paths. As a result, an authenticated user who is allowed to create topics or update topic properties in one tenant can bind a topic in that tenant to a persistent topic in any other tenant. With the default authorization provider, these operations require the tenant admin role for the user's own tenant. The user does not need any permission on the source topic, its namespace or its tenant. This impact analysis assumes that Pulsar has been configured with the default authorization provider. For custom authorization providers, the impact could be different. The user can then consume from the shadow topic, using only permissions on their own topic, and receive retained messages that were published to the source topic in the other tenant. Exposure is limited to messages that are still retained and readable in the source topic's ledgers; messages protected with client-side end-to-end encryption cannot be decrypted without the encryption keys. A producer on the shadow topic can also register a new schema version under the source topic's schema, subject to the schema compatibility settings; existing schema versions are not replaced. In addition, the shadow topic's managed ledger applies its own retention, trimming, offloading and deletion to the source topic's ledgers. This can permanently delete the source topic's ledger data from BookKeeper and from tiered storage, regardless of the source topic's own subscriptions and retention policy, including messages that have not yet been acknowledged. Deleting the shadow topic can also delete the source topic's ledgers. This data loss can also affect shadow topics that were configured intentionally by administrators. This issue affects Apache Pulsar versions from 3.0.0 before 4.0.14 and from 4.1.0 before 4.2.5. Apache Pulsar 2.x releases do not contain the shadow topic implementation. - 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. 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/. In the fixed versions, shadow topics are disabled by default and are controlled by the new broker configuration setting enableShadowTopics (default false). While it is disabled, the broker rejects creating shadow topics, setting the PULSAR.SHADOW SOURCE property, and loading or replicating to existing shadow topics. Deployments that use shadow topics must set enableShadowTopics=true in the broker configuration of all brokers after upgrading; otherwise existing shadow topics will not be loaded. When shadow topics are enabled, binding a shadow topic to a source topic in a different tenant requires the superuser role. The fixed versions also prevent a shadow topic from deleting or trimming the ledgers and offloaded data of its source topic. Affected versions provide no configuration option to disable shadow topics. Users who cannot upgrade immediately can reduce exposure by granting the tenant admin role only to trusted principals.

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 subscription's cursor forward, so unacknowledged messages are no longer delivered to the subscription's consumers. The unsubscribe operation deletes a subscription that has no connected consumers. Skipped messages can be permanently deleted once no other subscription or the namespace's 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 broker's admin REST API to trusted administrative clients.