Skip to content

Read permissions not enforced for client provided filter expressions in Elide.

High severity GitHub Reviewed Published Mar 28, 2020 in yahoo/elide • Updated Jan 9, 2023

Package

maven com.yahoo.elide:elide-core (Maven)

Affected versions

< 4.5.14

Patched versions

4.5.14

Description

Impact

It is possible for an adversary to "guess and check" the value of a model field they do not have access to assuming they can read at least one other field in the model. The adversary can construct filter expressions for an inaccessible field to filter a collection. The presence or absence of models in the returned collection can be used to reconstruct the value of the inaccessible field.

For example, a User model has two fields: name and role. The adversary has read permissions to see the name field of the User collection but not the role. By constructing a filter like the one below, the adversary can determine which users have admin role by presence or absence in the returned collection:
filter=role=="Admin"

Patches

Resolved in Elide 4.5.14 and greater.

Workarounds

The adversary can only access the fields if a model includes fields with different read permission levels (some less secure and some more secure). Model security can be adjusted by restricting read permissions on existing models.

References

Fixed in yahoo/elide#1236

For more information

If you have any questions or comments about this advisory:

References

@aklish aklish published to yahoo/elide Mar 28, 2020
Reviewed Mar 30, 2020
Published to the GitHub Advisory Database Mar 30, 2020
Last updated Jan 9, 2023

Severity

High

EPSS score

0.100%
(43rd percentile)

Weaknesses

CVE ID

CVE-2020-5289

GHSA ID

GHSA-2mxr-89gf-rc4v

Source code

No known source code
Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.