Dapr 1.11.2 [security]

This update contains security fixes:

• Security: API token authentication bypass in HTTP endpoints (Security advisory)
• Security: Potential DoS in avro dependency (CVE-2023-37475)

Additionally, this patch release contains bug fixes:

• Fixed: unbounded history batch save in Workflows
• Fixed: Workflows not working in some Kubernetes clusters
• Fixed a number of bugs in the gRPC Configuration Subscribe API

Security: API token authentication bypass in HTTP endpoints

Problem

Security advisory

A high-severity vulnerability has been found in Dapr that allows bypassing API token authentication, which is used by the Dapr sidecar to authenticate calls coming from the application, with a well-crafted HTTP request.

Impact

The vulnerability impacts all users on Dapr <=1.10.9 and <=1.11.2 who are using API token authentication.

Root cause

The Dapr sidecar allowed all requests containing /healthz in the URL (including query string) to bypass API token authentication.

Solution

We have changed the API token authentication middleware to allow bypassing the authentication only for healthcheck endpoints more strictly.

Security: Potential DoS in avro dependency (CVE-2023-37475)

Problem

CVE-2023-37475

An issue in the third-party avro dependency could cause a resource exhaustion and a DoS for Dapr.

Impact

This issue impacts users of Dapr that use the Pulsar components.

Root cause

The issue was in a third-party dependency.

Solution

We have upgraded the avro dependency to version 2.13.0 which contains a fix for the reported issue.

Fixed: unbounded history batch save in Workflows

Problem

Due to a bug in the workflow engine, the full workflow history was saved on each checkpoint, rather than only the deltas. This resulted in two problems:

• The I/O cost of saving workflow state increased over the lifetime of the workflow
• Using state stores which have limits on transaction batch sizes, for example Azure Cosmos DB, caused workflows with more than a few actions to fail permanently

Impact

The issue impacts users of Dapr Workflow on Dapr 1.10 and higher.

Root cause

The problem was caused by a coding issue: an object was passed by reference rather than as a pointer.

Solution

We fixed the issue in the source code and added new tests to prevent regressions.

Fixed: Workflows not working in some Kubernetes clusters

Problem

In some Kubernetes clusters, the workflow engine may not have been able to process work items and tasks that were part of a workflow. Calls to the workflow engine would time out and fail.

Impact

The issue impacts users of Dapr Workflows which run the Dapr gRPC server listening on more than one address. This is the default behavior on Kubernetes, where Dapr normally listens on both 127.0.0.1 (IPv4) an [::1] (IPv6). The issue can appear also outside of Kubernetes if users run Dapr with multiple values for --dapr-listen-addresses.

Root cause

A new instance of the workflow engine was attached to each Dapr gRPC listener independently. Depending on what protocol the application was using to connect to Dapr (IPv4 or IPv6), the request could hit a workflow engine that was not currently processing tasks, causing a deadlock.

Solution

We have changed the initialization code to ensure that Dapr uses a single instance of the workflow engine across all listeners.

Fixed a number of bugs in the gRPC Configuration Subscribe API

Problem

We identified a number of bugs, especially race conditions, in the gRPC implementation for the Configuration Subscribe API, which became stable in Dapr 1.11.0. These bugs could have caused the Subscribe API to behave unexpectedly.

Impact

The issue can impact users that are invoking the Configuration building block APIs using gRPC.

Root cause

The issues were traced back to a number of race conditions in the way the gRPC stream was handled.

Solution

We refactored the code to remove the race conditions and fix the bugs.