Description

In OpenFGA, under specific conditions, BatchCheck calls with multiple checks sent for the same object, relation, and user combination can result in improper policy enforcement.

Am I affected?

You are affected if you meet the following preconditions: 1. You execute BatchCheck operations which rely on context. 2. Multiple checks are sent within a single BatchCheck operation for the same user/object/relation combination, each containing context. 3. The contexts between those checks differ in a specific way

Fix Upgrade to OpenFGA v1.14.0

Acknowledgement OpenFGA would like to thank @bugbunny-research for the discovery and detailed report.

Description

OpenFGA's OIDC authenticator skipped JWT audience (aud) validation when no audience was configured. In deployments where one identity provider issues tokens for multiple services, a token minted for an unrelated service could authenticate to OpenFGA.

Preconditions

This applies if the following preconditions are met:

1. You run OpenFGA with authn.method set to oidc. 2. You configured authn.oidc.issuer but did not set authn.oidc.audience (--authn-oidc-audience / OPENFGAAUTHNOIDCAUDIENCE).

Fix

Upgrade to OpenFGA 1.18.0 or greater. OpenFGA now refuses to start in oidc mode unless both authn.oidc.issuer and authn.oidc.audience are set, and the aud claim is always validated.

Acknowledgements

OpenFGA would like to thank https://github.com/0xVijay for the report.

Description

In OpenFGA, when MySQL is being used as the datastore, two distinct check requests can return the same response.

Preconditions

This applies if the following preconditions are met:

1. You run OpenFGA with MySQL as the datastore 2. Your authorization decisions rely on case-sensitive user strings.

Fix Upgrade to OpenFGA 1.18.0 or greater.

Acknowledgements OpenFGA would like to thank @sahajamoth for the detailed report.

Description In OpenFGA, when iterator caching is enabled, two distinct check requests can produce the same cache key, leading to OpenFGA reusing an earlier cached result for a subsequent request.

Preconditions This applies if the following preconditions are present:

- FGA runs with SharedIteratorCache enabled, - FGA runs with ListObjectsIteratorCache enabled.

Fix Upgrade to version 1.16.0 or greater.

Acknowledgements OpenFGA would like to thank @j4xT for the discovery and the detailed report.

Description In OpenFGA, in specific scenarios, models using conditions with caching enabled can result in two different check requests producing the same cache key. This could result in OpenFGA reusing an earlier cached result for a subsequent request.

Am I Affected? Users are affected if their applications meet the following preconditions:

The model has relations which rely on condition evaluation. Caching is enabled.

Fix Upgrade to OpenFGA v1.14.1.

Acknowledgement OpenFGA would like to thank @bugbunny-research for the detailed report.

Impact OpenFGA v1.8.5 to v1.11.2 ( openfga-0.2.22 <= Helm chart <= openfga-0.2.51, v.1.8.5 <= docker <= v.1.11.2) are vulnerable to improper policy enforcement when certain Check calls are executed.

Affected Users Users are affected by this vulnerability if all of the following preconditions are met: - OpenFGA v1.8.5 to v1.11.2 is being used - The model has a relation directly assignable by a type bound public access and assignable by type bound non-public access - A tuple is assigned for the relation that is a type bound public access - A tuple is assigned for the same object with the same relation that is not type bound public access - A tuple is assigned for a different object that has an object ID lexicographically larger with the same user and relation which is not type bound public access

Fix Upgrade to v1.11.3. This upgrade is backwards compatible.

Workaround None

Overview OpenFGA v1.8.0 to v1.8.12 ( openfga-0.2.16 <= Helm chart <= openfga-0.2.31, v1.8.0 <= docker <= v.1.8.12) are vulnerable to authorization bypass when certain Check and ListObject calls are executed.

Am I Affected? If you are using OpenFGA v1.8.0 to v1.8.12, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an authorization model that has a relationship directly assignable by both type bound public access and userset, and - There are check or list object queries with contextual tuples for the relationship that can be directly assignable by both type bound public access and userset, and - Those contextual tuples’s user field is an userset, and - Type bound public access tuples are not assigned to the relationship

Fix Upgrade to v1.8.13. This upgrade is backwards compatible.

Acknowledgments Okta would like to thank @udyvish for discovering this vulnerability.

Overview OpenFGA v1.9.3 to v1.9.4 ( openfga-0.2.40 <= Helm chart <= openfga-0.2.41, v1.9.3 <= docker <= v.1.9.4) are vulnerable to improper policy enforcement when certain Check and ListObject calls are executed.

Am I Affected? You are affected by this vulnerability if you are using OpenFGA v1.9.3 to v1.9.4, specifically under the following preconditions: - Calling Check API or ListObjects with an authorization model that has a relationship directly assignable by more than 1 userset with same type, and - There are check or list object queries that rely on the above relationship, and - You have userset tuples that are assigned to the above relationship

Fix Upgrade to v1.9.5. This upgrade is backwards compatible.

Workaround Downgrade to v1.9.2 with enable-check-optimizations removed from OPENFGAEXPERIMENTALS

Acknowledgments OpenFGA would like Dominic Harries and rrozza-apolitical to thank for discovering this vulnerability.