Friday, December 19, 2014

Some links for understanding CVE-2014-9390

This is a particularly interesting CVE for me, because it's "right up my alley", as they say.

  • Git 1.8.5.6, 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.
    
  • 3f1509809e728b70ea7912e4e1b40f22965e45ee
    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.

No comments:

Post a Comment