GHSA-fvv5-h29g-f6w5: User with ci ReadAction Permissions And Write Permissions Vulnerability

MODERATE
CVSS 5.3
Published
Advisory Summary

GHSA-fvv5-h29g-f6w5 is a MODERATE (CVSS 5.3) readaction permissions and write permissions vulnerability (General Security Weakness) affecting User with ci libraries in the Go ecosystem. The issue involves readaction permissions and write permissions to one path in a repository may copy objects from any path in the repository. Remediation is available by upgrading affected packages to version 1.12.1.

GHSA-fvv5-h29g-f6w5 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-fvv5-h29g-f6w5
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification General Security Weakness
Affected Product User with ci
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity None (I:N)
Availability None (A:N)

How to Fix GHSA-fvv5-h29g-f6w5

To remediate this vulnerability, upgrade all affected User with ci dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/treeverse/lakefs fixed: 1.12.1
Upgrade github.com/treeverse/lakefs to 1.12.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/treeverse/lakefs

How to Check if You Are Affected

To determine whether your application is affected by GHSA-fvv5-h29g-f6w5, inspect your project dependencies for User with ci:

inspect dependencies for github.com/treeverse/lakefs

Analyze the terminal output to locate any version of User with ci in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.12.1), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under General Security Weakness. In User with ci, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Impact A bug in permissions validation allows a user with the `ci:ReadAction` permission to skip read checks when copying an object. If they additionally have read and write permission to path in the repository, they can copy an otherwise unreadable object and read it. In order to be affected and exploitable, the following conditions must ALL occur on the same user: 1. `ci:ReadAction` enabled for the repository. Predefined policies RepoManagementRead and RepoManagementFullAccess allow this action. 2. `fs:ReadObject` and `fs:WriteObject` enabled for some path. 3. `fs:ReadObject` _not_ available for some path Such a user can use (1) to copy the unreadable object (3) to a path that they can read and write (2). At that point they can read the object copy. ### Patches Releases >= 1.12.1 fix this issue in lakeFS. ### Workarounds As a workaround, use RBAC to deny `ci:*` permissions to all users, or to all users who have limited read access. Many installations are unaffected: * **Installations using ACLs are _not_ affected.** This includes all OSS installations that have not implemented an external authorization server. We do not know of any OSS installations that have implemented such a server. ACLs that allow ci:ReadAction also allow reading repositories, so no capabilities are granted. * **Installations using RBAC that use only predefined policies with "all" ARNs ("*") are _not_ affected.** This includes **all installations that have not defined any new groups in RBAC.** In order to be affected, **installations using RBAC** must define users and simultaneous allow `ci:ReadAction` and disallow `fs:ReadObject` for some path. `ci:ReadAction` is available in policies RepoManagementReadAll and RepoManagementFullAccess. By default these actions are configured for groups Developers and above, for all repositories and paths. ### References * [lakeFS RBAC](https://docs.lakefs.io/reference/security/rbac.html)

GHSA-fvv5-h29g-f6w5 Affected User with ci Versions

1 component(s)
Fixed Versions:
1.12.1
Product / Package Ecosystem Affected Versions Fixed Version
github.com/treeverse/lakefs
Go
≥ 0.90.0
< 1.12.1
1.12.1

References

Frequently Asked Questions

What is GHSA-fvv5-h29g-f6w5?
GHSA-fvv5-h29g-f6w5 is a security vulnerability in User with ci involving ReadAction permissions and write permissions to one path in a repository may copy objects from any path in the repository under General Security Weakness.
Which User with ci versions are affected?
Affected versions include releases prior to 1.12.1 across affected packages: github.com/treeverse/lakefs.
What version fixes GHSA-fvv5-h29g-f6w5?
Upgrading to 1.12.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/treeverse/lakefs affected?
Yes, github.com/treeverse/lakefs is affected in releases prior to 1.12.1. Upgrade your dependency to 1.12.1 or later.
What is the CVSS score of GHSA-fvv5-h29g-f6w5?
GHSA-fvv5-h29g-f6w5 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N.
What CWE is associated with GHSA-fvv5-h29g-f6w5?
GHSA-fvv5-h29g-f6w5 is classified under General Security Weakness.
How can I check Go dependencies for GHSA-fvv5-h29g-f6w5?
Run the dependency tree command: 'inspect dependencies for github.com/treeverse/lakefs'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-fvv5-h29g-f6w5",
  "modified" : "2024-02-22T21:36:04Z",
  "published" : "2024-02-22T21:36:04Z",
  "aliases" : [ ],
  "summary" : "User with ci:ReadAction permissions and write permissions to one path in a repository may copy objects from any path in the repository",
  "details" : "### Impact\n\nA bug in permissions validation allows a user with the `ci:ReadAction` permission to skip read checks when copying an object.  If they additionally have read and write permission to path in the repository, they can copy an otherwise unreadable object and read it.\n\nIn order to be affected and exploitable, the following conditions must ALL occur on the same user:\n1. `ci:ReadAction` enabled for the repository.  Predefined policies RepoManagementRead and RepoManagementFullAccess allow this action.\n2. `fs:ReadObject` and `fs:WriteObject` enabled for some path.\n3. `fs:ReadObject` _not_ available for some path\n\nSuch a user can use (1) to copy the unreadable object (3) to a path that they can read and write (2).  At that point they can read the object copy.\n\n### Patches\n\nReleases >= 1.12.1 fix this issue in lakeFS.\n\n### Workarounds\n\nAs a workaround, use RBAC to deny `ci:*` permissions to all users, or to all users who have limited read access.\n\nMany installations are unaffected:\n\n* **Installations using ACLs are _not_ affected.** This includes all OSS installations that have not implemented an external authorization server.  We do not know of any OSS installations that have implemented such a server.  ACLs that allow ci:ReadAction also allow reading repositories, so no capabilities are granted.\n* **Installations using RBAC that use only predefined policies with \"all\" ARNs (\"*\") are _not_ affected.**  This includes **all installations that have not defined any new groups in RBAC.**\n\nIn order to be affected, **installations using RBAC** must define users and simultaneous allow `ci:ReadAction` and disallow `fs:ReadObject` for some path.  `ci:ReadAction` is available in policies RepoManagementReadAll and RepoManagementFullAccess.  By default these actions are configured for groups Developers and above, for all repositories and paths.\n\n\n### References\n\n* [lakeFS RBAC](https://docs.lakefs.io/reference/security/rbac.html)\n\n",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/treeverse/lakefs"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.90.0"
      }, {
        "fixed" : "1.12.1"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 1.12.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/treeverse/lakeFS/security/advisories/GHSA-fvv5-h29g-f6w5"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/treeverse/lakeFS/commit/56556ee5406fc5425b9302cd08a8d412635fdcd7"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/treeverse/lakeFS"
  } ],
  "database_specific" : {
    "cwe_ids" : [ ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2024-02-22T21:36:04Z",
    "nvd_published_at" : null
  }
}