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://email@example.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.