Skip to content

cdo-local-uuid vulnerable to insertion of artifact derived from developer's Present Working Directory into demonstration code

Low severity GitHub Reviewed Published Jan 10, 2024 in Cyber-Domain-Ontology/CDO-Utility-Local-UUID • Updated Sep 13, 2024

Package

pip case-utils (pip)

Affected versions

= 0.5.0
= 0.6.0
= 0.7.0
= 0.8.0
= 0.9.0
= 0.10.0
= 0.11.0
= 0.12.0
= 0.13.0
= 0.14.0

Patched versions

0.5.1
0.6.1
0.7.1
0.8.1
0.9.1
0.10.1
0.11.1
0.12.1
0.13.1
0.14.1
pip cdo-local-uuid (pip)
= 0.4.0
0.5.0

Description

Impact

What kind of vulnerability is it? Who is impacted?

An information leakage vulnerability is present in cdo-local-uuid at version 0.4.0, and in case-utils in unpatched versions (matching the pattern 0.x.0) at and since 0.5.0, before 0.15.0.

The vulnerability stems from a Python function, cdo_local_uuid.local_uuid(), and its original implementation case_utils.local_uuid(). Henceforth, both will be called local_uuid().

local_uuid() generates UUIDv5s using a deterministic pseudorandom number stream. This was written to make graph application demonstrations generate consistent, version-controllable output with minimal noise caused by demonstration re-runs. Part of the information used to keep individual examples' generated output distinct from one another is seed information from the caller's environment, particularly the program's argument vector. The present working directory is also included as part of the seed information, but for reasons including maintaining user environment privacy, as well as keeping generated identifiers consistent regardless of where a source tree is housed on a user's file system, the present working directory is trimmed from the left to exclude path information outside of a supplied "Top" source directory. (In context of the Make scripting language, this "top" directory is typically in a variable called top_srcdir. In context of Git-based project management, this directory is expected to be the root directory of a freshly "Cloned" project, e.g., where .git is stored.)

Under certain conditions, a user's present working directory, as an absolute path, was incorporated into seed data for the local_uuid() deterministic pseudorandom number stream. This violates an expectation made in the documented purpose of the local_uuid() function, and leaks information about a calling user's environment.

The conditions are:

  • Given a project with top source directory top_srcdir, for instance /home/user1/Documents/Project1;
  • Given a Python script housed directly in top_srcdir, for instance at ${top_srcdir}/example.py, written to support the deterministic mode of local_uuid();
  • Given a call to that Python script that follows the documentation for local_uuid();

The absolute path for top_srcdir was then included in the seed information for the UUIDv5 stream, when what was intended was a relative path spelling. That is, instead of ./example.py being in the seed data, /home/user1/Documents/Project1/example.py was in the seed data.

This does not leak the present working directory directly. But, given other knowledge of how a program had been called to generate data using local_uuid() under these conditions, it becomes possible to determine that a chosen path can lead to a known UUIDv5 value. Note that it is not necessarily knowable that the chosen path is the only solution to a sequence reconstruction; but, the path can be confirmed to be a solution.

Patches

Has the problem been patched? What versions should users upgrade to?

The issue has been patched, in the cdo-local-uuid source repository and the case-utils source repository.

Users should upgrade to any of these versions minimally:

  • case-utils == 0.5.1
  • case-utils == 0.6.1
  • case-utils == 0.7.1
  • case-utils == 0.8.1
  • case-utils == 0.9.1
  • case-utils == 0.10.1
  • case-utils == 0.11.1
  • case-utils == 0.12.1
  • case-utils == 0.13.1
  • case-utils == 0.14.1
  • case-utils >= 0.15.0
  • cdo-local-uuid == 0.5.0

All case-utils releases that contain the patch have the commit ea630cce66b26dae6d7fa7e02451d6e25456a5f2 in their Git history. Anyone interested in confirming the presence of this commit in a certain branch or tag can run the following test (written in Bash), substituting the desired branch name for the assigned value of my_git_ref_of_interest:

#!/bin/bash
# Present working directory ($PWD) should be in a clone of this repository:
# https://github.com/casework/CASE-Utilities-Python
my_git_ref_of_interest=main
test \
  "xea630cce66b26dae6d7fa7e02451d6e25456a5f2" \
  == \
  "x$(git merge-base ea630cc ${my_git_ref_of_interest})"
echo $?  # Should print '0'

Note that other releases have been posted atop some of those minimal versions recommended for upgrading, named, e.g., 0.5.1.post0. These releases were posted to update internal library version numbers, and otherwise contain no functional changes, in accordance with Python Packaging guidance:

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If the script calling cdo_local_uuid.local_uuid() is moved out of the "Top" source directory, the issue is addressed.

References

Are there any links users can visit to find out more?

The issue is addressed in this Pull Request:

Tests to reproduce the issue's conditions and confirm it has been addressed are in this Pull Requested:

References

@ajnelson-nist ajnelson-nist published to Cyber-Domain-Ontology/CDO-Utility-Local-UUID Jan 10, 2024
Published by the National Vulnerability Database Jan 11, 2024
Published to the GitHub Advisory Database Jan 11, 2024
Reviewed Jan 11, 2024
Last updated Sep 13, 2024

Severity

Low

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 Present
Privileges Required Low
User interaction Passive
Vulnerable System Impact Metrics
Confidentiality Low
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:P/PR:L/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:U

EPSS score

0.044%
(11th percentile)

Weaknesses

CVE ID

CVE-2024-22194

GHSA ID

GHSA-rgrf-6mf5-m882

Source code

Credits

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