<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="sa-render.xsl"?>
  <update from="huaweicloud.com" type="security" status="stable" version="1">
    <id>HCE2-SA-2024-0155</id>
    <title>An update for git is now available for HCE 2.0</title>
    <severity>Critical</severity>
    <release>HCE 2.0</release>
    <issued date="2024-06-28 03:57:27"/>
    <updated date="2024-06-28 03:57:27"/>
    <references>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32021" id="CVE-2024-32021" title="CVE-2024-32021 Base Score: 3.9 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:L" type="cve"/>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32002" id="CVE-2024-32002" title="CVE-2024-32002 Base Score: 9.0 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H" type="cve"/>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32465" id="CVE-2024-32465" title="CVE-2024-32465 Base Score: 7.3 Vector: CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H" type="cve"/>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32020" id="CVE-2024-32020" title="CVE-2024-32020 Base Score: 3.9 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:L" type="cve"/>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24765" id="CVE-2022-24765" title="CVE-2022-24765 Base Score: 7.8 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" type="cve"/>
      <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32004" id="CVE-2024-32004" title="CVE-2024-32004 Base Score: 8.1 Vector: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H" type="cve"/>
    </references>
    <description>Security Fix(es):

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository_x27;s `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning
will be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. (CVE-2024-32021)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule_x27;s worktree but into a `.git/` directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via `git config --global core.symlinks false`), the described attack won_x27;t work. As always, it is best to avoid cloning repositories from untrusted sources. (CVE-2024-32002)

Git is a revision control system. The Git project recommends to avoid working in untrusted repositories, and instead to clone it first with `git clone --no-local` to obtain a clean copy. Git has specific protections to make that a safe operation even with an untrusted source repository, but vulnerabilities allow those protections to be bypassed. In the context of cloning local repositories owned by other users, this vulnerability has been covered in CVE-2024-32004. But there are circumstances where the fixes for CVE-2024-32004 are not enough: For example, when obtaining a `.zip` file containing a full copy of a Git repository, it should not be trusted by default to be safe, as e.g. hooks could be configured to run within the context of that repository. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid using Git in repositories that have been obtained via archives from untrusted sources. (CVE-2024-32465)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, local clones may end up hardlinking files into the target repository_x27;s object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a &quot;proper&quot; clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. (CVE-2024-32020)

Git for Windows is a fork of Git containing Windows-specific patches. This vulnerability affects users working on multi-user machines, where untrusted parties have write access to the same hard disk. Those untrusted parties could create the folder `C:\.git`, which would be picked up by Git operations run supposedly outside a repository while searching for a Git directory. Git would then respect any config in said Git directory. Git Bash users who set `GIT_PS1_SHOWDIRTYSTATE` are vulnerable as well. Users who installed posh-gitare vulnerable simply by starting a PowerShell. Users of IDEs such as Visual Studio are vulnerable: simply creating a new project would already read and respect the config specified in `C:\.git\config`. Users of the Microsoft fork of Git are vulnerable simply by starting a Git Bash. The problem has been patched in Git for Windows v2.35.2. Users unable to upgrade may create the folder `.git` on all drives where Git commands are run, and remove read/write access from those folders as a workaround. Alternatively, define or extend `GIT_CEILING_DIRECTORIES` to cover the _parent_ directory of the user profile, e.g. `C:\Users` if the user profile is located in `C:\Users\my-user-name`. (CVE-2022-24765)

Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, an attacker can prepare a local repository in such a way that, when cloned, will execute arbitrary code during the operation. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. As a workaround, avoid cloning repositories from untrusted sources. (CVE-2024-32004)
</description>
    <pkglist>
      <collection short="HCE 2.0" package="git">
        <name>HCE 2.0</name>
        <package arch="noarch" name="gitk" version="2.33.0" release="1.r13.hce2">
          <filename>gitk-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="aarch64" name="git" version="2.33.0" release="1.r13.hce2">
          <filename>git-2.33.0-1.r13.hce2.aarch64.rpm</filename>
        </package>
        <package arch="aarch64" name="git-daemon" version="2.33.0" release="1.r13.hce2">
          <filename>git-daemon-2.33.0-1.r13.hce2.aarch64.rpm</filename>
        </package>
        <package arch="noarch" name="git-email" version="2.33.0" release="1.r13.hce2">
          <filename>git-email-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="git-gui" version="2.33.0" release="1.r13.hce2">
          <filename>git-gui-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="git-help" version="2.33.0" release="1.r13.hce2">
          <filename>git-help-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="git-svn" version="2.33.0" release="1.r13.hce2">
          <filename>git-svn-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="git-web" version="2.33.0" release="1.r13.hce2">
          <filename>git-web-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="perl-Git" version="2.33.0" release="1.r13.hce2">
          <filename>perl-Git-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="noarch" name="perl-Git-SVN" version="2.33.0" release="1.r13.hce2">
          <filename>perl-Git-SVN-2.33.0-1.r13.hce2.noarch.rpm</filename>
        </package>
        <package arch="x86_64" name="git" version="2.33.0" release="1.r13.hce2">
          <filename>git-2.33.0-1.r13.hce2.x86_64.rpm</filename>
        </package>
        <package arch="x86_64" name="git-daemon" version="2.33.0" release="1.r13.hce2">
          <filename>git-daemon-2.33.0-1.r13.hce2.x86_64.rpm</filename>
        </package>
      </collection>
    </pkglist>
  </update>
