Skip to content

Improper Authorization in Select Permissions

High severity GitHub Reviewed Published Oct 8, 2024 in surrealdb/surrealdb • Updated Oct 8, 2024

Package

cargo surrealdb (Rust)

Affected versions

< 2.0.4

Patched versions

2.0.4
cargo surrealdb-core (Rust)
< 2.0.4
2.0.4

Description

Due to the order in which permissions were processed, some statements, filters and computations could lead to leaking field values or record contents to users without the required permissions. This behavior could be triggered in different scenarios:

  • When performing a SELECT operation on a table, the values that would be returned were iterated over, field permissions would be validated and any unauthorized value would be removed from the result returned. However, performing a SELECT VALUE operation (e.g. SELECT VALUE private FROM data) would result in a non-iterable value, which would not be removed from the returned result.

  • When aliasing a field (e.g. SELECT private AS public FROM data) for which the user did not have SELECT permissions within a SELECT query, permissions would be checked against the field of the resulting document containing the aliased field instead of the original document containing the original field. As a consequence, the original field value would be returned as the returned field would not match the original field where permissions had been defined.

  • When calling a function in the context of a SELECT query and passing a field with permissions as an argument to the function (e.g. SELECT string::lowercase(private) FROM data), the function would receive the field value before it had been removed from the document due to SELECT permissions. As a result, the function would have access to the value of the field regardless of field permissions. This case includes functions called from within events and other clauses that support function calling.

  • When executing a query containing a WHERE clause filtering records by a field that the querying user does not have access to SELECT (e.g. SELECT public FROM data WHERE private ~ "secret"), the response of that query would still take the value of the field into account. Even though the value of the protected field would not be returned, this behavior could be used as a side channel by the querying user to infer information about the value of the field.

  • When performing UPDATE or DELETE operations over a table with a user that had those permissions but no SELECT permission, the RETURN BEFORE clause could be used (e.g. DELETE data RETURN BEFORE) to read the contents of the records prior to the authorized update or the deletion despite the querying user not being authorized to perform SELECT operations.

  • When performing UPDATE operations on a table for which the user had SELECT and UPDATE permissions, the SET clause could reference fields that the user had UPDATE but no SELECT permission for (e.g. UPDATE data SET public = private) in order to update the value of a field that the user had permission to SELECT to the value of another field for which the user did not.

Impact

Clients that were authorized by table permissions to execute SELECT statements for a table but were not authorized by field permissions to run SELECT queries for a specific field could still have been able to gain knowledge of the value of that field. Additionally, clients that were authorized to execute UPDATE or DELETE statements for a table but not authorized to execute SELECT statements for the same table may have been able to gain knowledge of the contents of records in that table. This could only be exploited by users who were already authorized to execute queries on the database with the affected table or field.

Due to its relationship with table and field permissions, which apply mainly to record users rather than system users, this issue mostly affects users relying on SurrealDB as a backend-as-a-service rather than SurrealDB as a traditional database backend.

Patches

The behavior when evaluating table or field permissions and filtering records or fields as a result of those evaluations has been improved to consider permissions before any changes to the document have been made and, when relevant, permissions after changes to the document have taken place. When a user is unauthorized to view record contents and field values by permissions, the returned documents will behave as if the record or field did not exist in order to prevent leaking any information.

  • Version 2.0.4 and later are not affected by this issue.

Workarounds

Users affected by this issue and unable to update should not rely on the authorization provided by field permissions when it comes to the SELECT permission. Instead, read access to fields in affected versions should be restricted at the table level. When allowing the UPDATE or DELETE operations for records via table permissions, users should not rely of the authorization provided by the SELECT permission. Instead, users should not allow clients to UPDATE or DELETE records that they should not be able to view.

References

@gguillemas gguillemas published to surrealdb/surrealdb Oct 8, 2024
Published to the GitHub Advisory Database Oct 8, 2024
Reviewed Oct 8, 2024
Last updated Oct 8, 2024

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Weaknesses

CVE ID

No known CVE

GHSA ID

GHSA-9722-9j67-vjcr

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.