Bug 1781143 (CVE-2019-1349) - CVE-2019-1349 git: Recursive submodule cloning allows using git directory twice with synonymous directory name written in .git/
Summary: CVE-2019-1349 git: Recursive submodule cloning allows using git directory twi...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2019-1349
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1781957 1784366 1784367 1784368 1784615 1784616 1784617 1785180 1785181
Blocks: 1781145
TreeView+ depends on / blocked
 
Reported: 2019-12-09 12:10 UTC by Dhananjay Arunesh
Modified: 2021-02-16 20:56 UTC (History)
36 users (show)

Fixed In Version: git 2.24.1, git 2.23.1, git 2.22.2, git 2.21.1, git 2.20.2, git 2.19.3, git 2.18.2, git 2.17.3, git 2.16.6, git 2.15.4, git 2.14.6
Doc Type: If docs needed, set a value
Doc Text:
An improper input validation flaw was discovered in git in the way it handles git submodules. A remote attacker could abuse this flaw to trick a victim user into recursively cloning a malicious repository, which, under certain circumstances, could fool git into using the same git directory twice and potentially cause remote code execution.
Clone Of:
Environment:
Last Closed: 2019-12-19 20:09:32 UTC
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:0003 0 None None None 2020-01-02 10:58:34 UTC
Red Hat Product Errata RHBA-2020:0025 0 None None None 2020-01-06 13:23:14 UTC
Red Hat Product Errata RHBA-2020:0032 0 None None None 2020-01-06 21:07:04 UTC
Red Hat Product Errata RHBA-2020:0125 0 None None None 2020-01-16 13:09:49 UTC
Red Hat Product Errata RHSA-2019:4356 0 None None None 2019-12-19 18:43:58 UTC
Red Hat Product Errata RHSA-2020:0002 0 None None None 2020-01-02 08:54:01 UTC
Red Hat Product Errata RHSA-2020:0228 0 None None None 2020-01-27 08:54:15 UTC

Description Dhananjay Arunesh 2019-12-09 12:10:38 UTC 
When using submodule paths that refer to the same file system entity (e.g. using the NTFS Alternate Data Streams attack mentioned in CVE-2019-1352 where files would be written to the `.git/` directory using a synonymous directory name), it was possible to "squat" on the `git~1` shortname on NTFS drives, opening attacks via `git~2`. This also affects Git when run as a Linux application inside the Windows Subsystem for Linux.

References:

https://kernel.googlesource.com/pub/scm/git/git/+/refs/tags/v2.24.1/Documentation/RelNotes/2.14.6.txt
Comment 1 Pedro Sampaio 2019-12-11 00:04:16 UTC 
Created git tracking bugs for this issue:

Affects: fedora-all [bug 1781957]
Comment 2 Riccardo Schirone 2019-12-13 16:24:38 UTC 
oss-security mailing list reference:
https://www.openwall.com/lists/oss-security/2019/12/13/1
Comment 3 Riccardo Schirone 2019-12-13 16:24:40 UTC 
External References:

https://github.com/git/git/security/advisories/GHSA-4qvh-qvv7-frc7
Comment 4 Riccardo Schirone 2019-12-16 15:30:17 UTC 
Upstream fix:
https://github.com/git/git/commit/0060fd1511b94c918928fa3708f69a3f33895a4a
Comment 5 Riccardo Schirone 2019-12-16 15:31:28 UTC 
Mitigation:

Avoid running `git clone --recurse-submodules` and `git submodule update` with untrusted repositories.
Comment 6 Riccardo Schirone 2019-12-17 10:23:16 UTC 
Git may be tricked into using a non-empty directory as a path for a submodule while recursively cloning a repository. This could potentially be used to overwrite the .git directory and remotely execute code.

However, this mainly affects Git for Windows and although in theory it may affects any platform where Git is used to clone onto a mounted network drive, we believe a Moderate impact better reflects the flaw. This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the system under certain circumstances.
Comment 8 Riccardo Schirone 2019-12-17 10:38:10 UTC 
The versions of git as shipped with Red Hat Enterprise Linux 6 already perform a check in the module_clone() function in git-submodule.sh, to ensure that the path is empty. If it is not, it tries to remove it and fail if that is not possible.

The versions of git as shipped with Red Hat Enterprise Linux 7, and 8 do not perform any check on the path during the module_clone() function, thus they are potentially affected by this flaw.
Comment 10 msiddiqu 2019-12-17 20:54:58 UTC 
Created libgit2 tracking bugs for this issue:

Affects: epel-6 [bug 1784617]
Affects: fedora-all [bug 1784616]


Created libgit2-glib tracking bugs for this issue:

Affects: fedora-all [bug 1784615]
Comment 15 errata-xmlrpc 2019-12-19 18:43:56 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2019:4356 https://access.redhat.com/errata/RHSA-2019:4356
Comment 16 Product Security DevOps Team 2019-12-19 20:09:32 UTC 
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2019-1349
Comment 17 errata-xmlrpc 2020-01-02 08:53:56 UTC 
This issue has been addressed in the following products:

  Red Hat Software Collections for Red Hat Enterprise Linux 7
  Red Hat Software Collections for Red Hat Enterprise Linux 7.6 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.5 EUS
  Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS

Via RHSA-2020:0002 https://access.redhat.com/errata/RHSA-2020:0002
Comment 21 errata-xmlrpc 2020-01-27 08:54:13 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions

Via RHSA-2020:0228 https://access.redhat.com/errata/RHSA-2020:0228
Note You need to log in before you can comment on or make changes to this bug.