This is a particularly interesting CVE for me, because it's "right up my alley", as they say.
- Git 126.96.36.199, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land
Git maintains various meta-information for its repository in files in .git/ directory located at the root of the working tree. The system does not allow a file in that directory (e.g. .git/config) to be committed in the history of the project, or checked out to the working tree from the project. Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker).
- [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)
Fixes since v2.2 ---------------- * We used to allow committing a path ".Git/config" with Git that is running on a case sensitive filesystem, but an attempt to check out such a path with Git that runs on a case insensitive filesystem would have clobbered ".git/config", which is definitely not what the user would have expected. Git now prevents you from tracking a path with ".Git" (in any case combination) as a path component. * On Windows, certain path components that are different from ".git" are mapped to ".git", e.g. "git~1/config" is treated as if it were ".git/config". HFS+ has a similar issue, where certain unicode codepoints are ignored, e.g. ".g\u200cit/config" is treated as if it were ".git/config". Pathnames with these potential issues are rejected on the affected systems. Git on systems that are not affected by this issue (e.g. Linux) can also be configured to reject them to ensure cross platform interoperability of the hosted projects. * "git fsck" notices a tree object that records such a path that can be confused with ".git", and with receive.fsckObjects configuration set to true, an attempt to "git push" such a tree object will be rejected. Such a path may not be a problem on some filesystems but in order to protect those on HFS+ and on case insensitive filesystems, this check is enabled on all platforms. A big "thanks!" for bringing this issue to us goes to our friends in the Mercurial land, namely, Matt Mackall and Augie Fackler.
fsck: complain about NTFS ".git" aliases in trees read-cache: optionally disallow NTFS .git variants path: add is_ntfs_dotgit() helper fsck: complain about HFS+ ".git" aliases in trees read-cache: optionally disallow HFS+ .git variants utf8: add is_hfs_dotgit() helper fsck: notice .git case-insensitively t1450: refactor ".", "..", and ".git" fsck tests verify_dotfile(): reject .git case-insensitively read-tree: add tests for confusing paths like ".." and ".git" unpack-trees: propagate errors adding entries to the index
- Git vulnerability with .git\config
Normally the git client avoids ever overwriting that file. Even if you commit a .git\config file and push it to a shared repo, no one else’s Git client will check it out into their private repos. However, a bug was discovered where various permutations of the .git folder name (e.g. mixed case, gIT, GiT, etc, Windows filename shortening .git~123, Ignorable Unicode codepoints .g\u200cit\config, etc) were not caught be the Git client’s filtering logic. As such, if someone pushed a malicious config file with one of these permutations, other people’s Git clients would check them out, overwriting their personal config file and hijacking their Git commands. This affects, at least, Windows NTFS and Mac OS X HFS+ filesystems, both of which are case insensitive filesystems.
- Vulnerability announced: update your Git clients
Repositories hosted on github.com cannot contain any of the malicious trees that trigger the vulnerability because we now verify and block these trees on push. We have also completed an automated scan of all existing content on github.com to look for malicious content that might have been pushed to our site before this vulnerability was discovered. This work is an extension of the data-quality checks we have always performed on repositories pushed to our servers to protect our users against malformed or malicious Git data.