Bug 1781143 (CVE-2019-1349)

Summary: CVE-2019-1349 git: Recursive submodule cloning allows using git directory twice with synonymous directory name written in .git/
Product: [Other] Security Response Reporter: Dhananjay Arunesh <darunesh>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: abenaiss, aileenc, amahdal, aos-bugs, besser82, bmontgom, c.david86, chazlett, chrisw, drieden, eparis, ggaughan, hhorak, i, icq, igor.raits, janstey, jburrell, jochrist, jokerman, jorton, jwon, klember, nstielau, opohorel, pbhattac, pcahyna, psampaio, pstodulk, rtillery, sebastian.kisela, security-response-team, sponnaga, tmz, vbobade, walter.pete
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-12-19 20:09:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1781957, 1784366, 1784367, 1784368, 1784615, 1784616, 1784617, 1785180, 1785181    
Bug Blocks: 1781145    

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