Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 13 Dec 2019 11:22:01 +0100 (CET)
From: Johannes Schindelin <Johannes.Schindelin@....de>
To: oss-security@...ts.openwall.com
Subject: Multiple vulnerabilities fixed in Git

Team,

[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:
https://lore.kernel.org/git/xmqqr21cqcn9.fsf@gitster-ct.c.googlers.com/T/#u

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):
https://github.com/git-for-windows/git/releases/tag/v2.24.1.windows.2

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
   payload.

   See also the advisory at
   https://github.com/git/git/security/advisories/GHSA-2pw3-gwg9-8pqr

 * 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
   clone.

   See also the advisory at
   https://github.com/git/git/security/advisories/GHSA-4qvh-qvv7-frc7

 * 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
   https://github.com/git/git/security/advisories/GHSA-44fr-r2hj-3f4x

 * 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
   https://github.com/git/git/security/advisories/GHSA-39hj-fvvf-mq4f

 * 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
   https://github.com/git/git/security/advisories/GHSA-5wph-8frv-58vj

 * 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 (https://docs.microsoft.com/en-us/windows/wsl/about)
   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
   https://github.com/git/git/security/advisories/GHSA-589j-mmg9-733v

 * 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
   https://github.com/git/git/security/advisories/GHSA-xjx4-8694-q2fq

 * 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
   `user.name`/`user.email` 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
   https://github.com/git/git/security/advisories/GHSA-4wfr-gwrh-8mj2

 * 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
   https://github.com/git/git/security/advisories/GHSA-cj5c-9839-g2ch

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
Singh.

Thanks,
Johannes

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.