Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12888 closed enhancement (fixed)


Reported by: ken@… Owned by: ken@…
Priority: high Milestone: 9.1
Component: BOOK Version: SVN
Severity: normal Keywords:


Announced on lkml among other places

Today, the Git project is releasing the following Git versions:

v2.24.1, v2.23.1, v2.22.2, v2.21.1, v2.20.2, v2.19.3, v2.18.2, v2.17.3, v2.16.6, v2.15.4, and v2.14.6

These releases fix various security flaws, which allowed an attacker to overwrite arbitrary paths, remotely execute code, and/or overwrite files in the .git/ directory etc. See the release notes attached for the list for their descriptions and CVE identifiers.

Users of the affected maintenance tracks are urged to upgrade.

These flaws were discovered and reported by Joern Schneeweisz of GitLab and by Microsoft Security Response Center (and in particular Nicolas Joly), and were fixed by Johannes Schindelin, Jeff King, Garima Singh and Jonathan Nieder on the git-security mailing list. The release engineering and coordination was led by Johannes Schindelin.

Git v2.24.1 Release Notes =========================

This release merges up the fixes that appear in v2.14.6, v2.15.4, v2.17.3, v2.20.2 and in v2.21.1, addressing the security issues CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387, and CVE-2019-19604; see the release notes for those versions for details.

Change History (4)

comment:1 by ken@…, 4 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

Since we are into December, I was inclined to try using python3 for this, with PYTHON=python3. But the tests are ending in error and I can't see any reported errors.

Earlier I did this pointing git to python3 using --with-python=/usr/bin/python3 and the tests ran ok, but at that time I had python2 available (I've now moved it out of the way).

Diffing the test output is hard (the order is a bit random), but the latest build appears to have run everything, then failed in 'make aggregate-results' which just invokes a shell script.

Giving up on 3 for the moment.

I note that fedora build with python3, but of course their python _is_ 3.

comment:2 by ken@…, 4 years ago

Resolution: fixed
Status: assignedclosed

comment:3 by ken@…, 4 years ago

I went back to python3 for my own build, using

PYTHON=python3 ./configure ... --with-python=/usr/bin/python3


PYTHON=python3 make $MAKEFLAGS test

(obviously make itself should be using py3, but with the tests, who knows) and on two systems where python2 has already been installed that seems to work ok.

comment:4 by Douglas R. Reno, 4 years ago

Here are some more details from oss-security:


[this is my first contribution to this list, I apologize in advance for
any mistakes I made.]

The Git project released new versions this past Tuesday, December 10th,
2019, addressing a whopping 9 CVEs.

All supported platforms are affected in one way or another, and apart from
CVE-2019-19604 (which affects only Git v2.20.0 and later), all Git
versions all the way back to 2.14.5 are affected (probably earlier ones,
too, we just stopped looking further as the 2.14.x release train is the
oldest we still service).

The fixed versions are: 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3,
2.18.2, 2.17.3, 2.16.6, 2.15.4, and 2.14.6. Link to the announcement:

Git for Windows v2.24.1(2) is the only fixed version on Windows (there are
only backports for the MinGit subset of Git for Windows):

We highly recommend to upgrade. The addressed issues are:

 * CVE-2019-1348:
   The --export-marks option of git fast-import is exposed also via
   the in-stream command feature export-marks=... and it allows
   overwriting arbitrary paths.

   The most obvious attack is to ask targeted users to import a malicious

   See also the advisory at

 * CVE-2019-1349:
   When submodules are cloned recursively, under certain circumstances
   Git could be fooled into using the same Git directory twice. We now
   require the directory to be empty.

   Our exploits for CVE-2019-1349 require Windows, but our impression is
   that there might be a way to exploit this also on macOS (and possibly
   Linux, maybe running in Windows Subsystem for Linux).

   The exploit we found was to write a file `.git.1` into the submodule
   directory (which would be associated with the NTFS short name `git~1`)
   so that the second submodule, by reusing the same directory, would have
   the NTFS short name `git~2` associated with the `.git` file, allowing
   the `.git` file to be overwritten despite the protections of
   `core.protectNTFS`, allowing remote code execution during a recursive

   See also the advisory at

 * CVE-2019-1350:
   Incorrect quoting of command-line arguments allowed remote code
   execution during a recursive clone in conjunction with SSH URLs.

   This is a Windows-only issue, as the vulnerable code is only compiled
   on Windows. The exploit we found involves a submodule having a name
   that ends in a backslash, and a maliciously-crafted SSH URL that
   exploits the bug to pass arbitrary options to `ssh.exe`, allowing
   remote code to be executed during a recursive clone.

   See also the advisory at

 * CVE-2019-1351:
   While the only permitted drive letters for physical drives on
   Windows are letters of the US-English alphabet, this restriction
   does not apply to virtual drives assigned via subst <letter>:
   <path>. Git mistook such paths for relative paths, allowing writing
   outside of the worktree while cloning.

   This vulnerability can only be exploited on Windows, and only when the
   targeted user is known to use non-alphabetical drive letters on logical
   drives registered with the `subst.exe` command, allowing to overwrite
   arbitrary files on said logical drive during a regular `git clone`.

   See also the advisory at

 * CVE-2019-1352:
   Git was unaware of NTFS Alternate Data Streams, allowing files
   inside the .git/ directory to be overwritten during a clone.

   While the description contains "NTFS", this vulnerability can not only
   be exploited on Windows, but also on macOS when working on
   `smb://`-mounted network shares. The exploit involves naming a
   directory `.git::$INDEX_ALLOCATION`, allowing remote code execution
   during a regular `git clone`.

   The fix for this CVE requires the fix for CVE-2019-1353.

   See also the advisory at

 * CVE-2019-1353:
   When running Git in the Windows Subsystem for Linux (also known as
   "WSL") while accessing a working directory on a regular Windows
   drive, none of the NTFS protections were active.

   This vulnerability affects Git when running inside the Windows
   Subsystem for Linux (
   and only when working on Windows drives where NTFS short names are
   enabled (which is the case, by default, for the system drive, i.e. `C:`).

   The exploit uses a directory named `git~1` and it allows remote code
   execution during a regular `git clone`.

   For this reason, Git now turns on `core.protectNTFS` by default, which
   is also required to address CVE-2019-1352.

   See also the advisory at

 * CVE-2019-1354:
   Filenames on Linux/Unix can contain backslashes. On Windows,
   backslashes are directory separators. Git did not use to refuse to
   write out tracked files with such filenames.

   This is a Windows-only vulnerability. The exploit uses backslashes in
   the file names stored in tree objects, allowing arbitrary files even
   outside of the Git worktree to be (over-)written.

   See also the advisory at

 * CVE-2019-1387:
   Recursive clones are currently affected by a vulnerability that is
   caused by too-lax validation of submodule names, allowing very
   targeted attacks via remote code execution in recursive clones.

   This is a fun one, as the only exploit we found is _very_ complex,
   _and_ it allows for only very targeted attacks as not only the
   ``/`` of the targeted user have to be known, it also
   requires controlling at least one web server from which at least one
   submodule is served. The exploit also requires colons to be valid
   characters in file names, i.e. it does not work if the targeted user
   uses Windows (unless using Git inside the Windows Subsystem for Linux).

   The idea is to force Git to create two files in the same directory,
   commondir and HEAD. This will fool Git into believing that this is a
   valid Git directory. As both `commondir` and `HEAD` are valid branch
   names, it is possible to abuse the reflogs directory for that. By
   default, the reflogs' contents have the format

   	<old-hash> <new-hash> <ident> <epoch> <tz><tab>clone: from <url>

   By naming another submodule so that its name nests with the reflogs
   directory, we can ensure that a directory exists whose name is identical
   to the first part of the reflog entry right up until the first slash of
   the URL (this contains colons, and is therefore not a legal directory
   name on Windows). By using `../` in the URL, this can break out of the git
   directory and redirect the commondir to a directory that was written as
   part of the recursive clone.

   Note that the targeted user's ident needs to be known, as well as at
   least a reasonably small time range of the attack, to allow for crafting
   such submodule names.

   Note also that for a remote code execution _during_ the recursive clone,
   the attacker needs to control a web server that backs one of the
   submodules, to pretend that at least one of the refs is updated _during_
   the recursive clone (which will ask for the set of refs _twice_, and
   only when cloning via HTTP/HTTPS).

   See also the advisory at

 * CVE-2019-19604:
   It is now disallowed for `.gitmodules` to have entries that set
   `submodule.<name>.update=!<command>`. This fixes the vulnerability
   in Git v2.20.0 and later where a recursive clone followed by a
   submodule update could execute code contained within the repository
   without the user explicitly having asked for that.

   The exploit stores a command in the `.gitmodules` file that points to a
   script or executable that is written as part of the initial clone.

   Technically, this is not a remote code execution vulnerability because
   there is a time window between the initial recursive clone and the call
   to `git submodule update` during which the user can inspect the
   malicious payload.

   See also the advisory at

Credit for finding the first 8 vulnerabilities goes to Microsoft Security
Response Center, in particular to Nicolas Joly. Credit for finding the
submodule `update=!command` vulnerability goes to Joern Schneeweisz,
credit for fixing it goes to Jonathan Nieder. The `fast-import` fixes were
provided by Jeff King, the other fixes by myself with help from Garima

Note: See TracTickets for help on using tickets.