CVE Vulnerabilities

CVE-2022-39253

Exposure of Sensitive Information to an Unauthorized Actor

Published: Oct 19, 2022 | Modified: Nov 21, 2024
CVSS 3.x
5.5
MEDIUM
Source:
NVD
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
CVSS 2.x
RedHat/V2
RedHat/V3
5.5 MODERATE
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
Ubuntu
MEDIUM

Git is an open source, scalable, distributed revision control system. Versions prior to 2.30.6, 2.31.5, 2.32.4, 2.33.5, 2.34.5, 2.35.5, 2.36.3, and 2.37.4 are subject to exposure of sensitive information to a malicious actor. When performing a local clone (where the source and target of the clone are on the same volume), Git copies the contents of the sources $GIT_DIR/objects directory into the destination by either creating hardlinks to the source contents, or copying them (if hardlinks are disabled via --no-hardlinks). A malicious actor could convince a victim to clone a repository with a symbolic link pointing at sensitive information on the victims machine. This can be done either by having the victim clone a malicious repository on the same machine, or having them clone a malicious repository embedded as a bare repository via a submodule from any source, provided they clone with the --recurse-submodules option. Git does not create symbolic links in the $GIT_DIR/objects directory. The problem has been patched in the versions published on 2022-10-18, and backported to v2.30.x. Potential workarounds: Avoid cloning untrusted repositories using the --local optimization when on a shared machine, either by passing the --no-local option to git clone or cloning from a URL that uses the file:// scheme. Alternatively, avoid cloning repositories from untrusted sources with --recurse-submodules or run git config --global protocol.file.allow user.

Weakness

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

Affected Software

Name Vendor Start Version End Version
Git Git-scm * 2.30.6 (excluding)
Git Git-scm 2.31.0 (including) 2.31.5 (excluding)
Git Git-scm 2.32.0 (including) 2.32.4 (excluding)
Git Git-scm 2.33.0 (including) 2.33.5 (excluding)
Git Git-scm 2.34.0 (including) 2.34.5 (excluding)
Git Git-scm 2.35.0 (including) 2.35.5 (excluding)
Git Git-scm 2.36.0 (including) 2.36.3 (excluding)
Git Git-scm 2.37.0 (including) 2.37.4 (excluding)
Git Git-scm 2.38.0 (including) 2.38.0 (including)
Red Hat Enterprise Linux 8 RedHat git-0:2.39.1-1.el8 *
Red Hat Enterprise Linux 8.6 Extended Update Support RedHat git-0:2.31.8-1.el8_6 *
Red Hat Enterprise Linux 9 RedHat git-0:2.39.1-1.el9 *
Git Ubuntu bionic *
Git Ubuntu devel *
Git Ubuntu esm-infra/xenial *
Git Ubuntu focal *
Git Ubuntu jammy *
Git Ubuntu kinetic *
Git Ubuntu lunar *
Git Ubuntu trusty *
Git Ubuntu xenial *

Extended Description

There are many different kinds of mistakes that introduce information exposures. The severity of the error can range widely, depending on the context in which the product operates, the type of sensitive information that is revealed, and the benefits it may provide to an attacker. Some kinds of sensitive information include:

Information might be sensitive to different parties, each of which may have their own expectations for whether the information should be protected. These parties include:

Information exposures can occur in different ways:

It is common practice to describe any loss of confidentiality as an “information exposure,” but this can lead to overuse of CWE-200 in CWE mapping. From the CWE perspective, loss of confidentiality is a technical impact that can arise from dozens of different weaknesses, such as insecure file permissions or out-of-bounds read. CWE-200 and its lower-level descendants are intended to cover the mistakes that occur in behaviors that explicitly manage, store, transfer, or cleanse sensitive information.

Potential Mitigations

  • Compartmentalize the system to have “safe” areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
  • Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

References