Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-9m7r-g8hg-x3vr: SpiceDB: LookupResources with Multiple Entrypoints across Different Definitions Can Return Incomplete Results

Impact

If a schema includes the following characteristics:

  1. Permission defined in terms of a union (+)
  2. That union references the same relation on both sides, but one side arrows to a different permission

Then you might have missing LookupResources results when checking the permission. This only affects LookupResources; other APIs calculate permissionship correctly.

A small concrete example:

relation doer_of_things: user | group#member
permission do_the_thing = doer_of_things + doer_of_things->admin

A CheckPermission on do_the_thing will return the correct permissionship, but a LookupResources on do_the_thing may miss resources.

A Comprehensive Example

If you have a schema with a structure like this:

definition special_user {}

definition user {
  relation special_user_mapping: special_user
  permission special_user = special_user_mapping
}
definition group {
   relation member: user
   permission membership = member + member->special_user
}

definition system {
  relation viewer: user | group#membership
  // This is the problematic permission
  permission view = viewer + viewer->special_user
}

And these relationships:

system:somesystem#viewer@group:somegroup#membership
group:somegroup#member@user:someuser1
user:someuser1#special_user_mapping@special_user:specialuser

And you call LookupResources with:

subject_type: user
subject_id: someuser1
permission: view
resource_type: system

You would expect to receive system:somesystem in the results, but you do not.

Note that this only applies to LookupResources; if you CheckPermission for that resource specifically, it will return HasPermission.

Patches

The issue is fixed in v1.47.1. Upgrading to this version will remediate this issue.

ghsa
#auth

Impact

If a schema includes the following characteristics:

  1. Permission defined in terms of a union (+)
  2. That union references the same relation on both sides, but one side arrows to a different permission

Then you might have missing LookupResources results when checking the permission. This only affects LookupResources; other APIs calculate permissionship correctly.

A small concrete example:

relation doer_of_things: user | group#member
permission do_the_thing = doer_of_things + doer_of_things->admin

A CheckPermission on do_the_thing will return the correct permissionship, but a LookupResources on do_the_thing may miss resources.

A Comprehensive Example

If you have a schema with a structure like this:

definition special_user {}

definition user {
  relation special_user_mapping: special_user
  permission special_user = special_user_mapping
}
definition group {
   relation member: user
   permission membership = member + member->special_user
}

definition system {
  relation viewer: user | group#membership
  // This is the problematic permission
  permission view = viewer + viewer->special_user
}

And these relationships:

system:somesystem#viewer@group:somegroup#membership
group:somegroup#member@user:someuser1
user:someuser1#special_user_mapping@special_user:specialuser

And you call LookupResources with:

subject_type: user
subject_id: someuser1
permission: view
resource_type: system

You would expect to receive system:somesystem in the results, but you do not.

Note that this only applies to LookupResources; if you CheckPermission for that resource specifically, it will return HasPermission.

Patches

The issue is fixed in v1.47.1. Upgrading to this version will remediate this issue.

References

  • GHSA-9m7r-g8hg-x3vr
  • authzed/spicedb@8c2edbe

ghsa: Latest News

GHSA-jf9p-2fv9-2jp2: thread-amount Vulnerable to Resource Exhaustion (Memory and Handle Leaks) on Windows and macOS