#12888: git-2.24.1
-------------------------+---------------------
Reporter: ken@… | Owner: ken@…
Type: enhancement | Status: closed
Priority: high | Milestone: 9.1
Component: BOOK | Version: SVN
Severity: normal | Resolution: fixed
Keywords: |
-------------------------+---------------------
Comment (by renodr):
Here are some more details from oss-security:
{{{
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
}}}
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/12888#comment:4>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
