Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security

Critical Git Security Vulnerability Announced 148

An anonymous reader writes Github has announced a security vulnerability and has encouraged users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem....Updated versions of GitHub for Windows and GitHub for Mac are available for immediate download, and both contain the security fix on the Desktop application itself and on the bundled version of the Git command-line client."
This discussion has been archived. No new comments can be posted.

Critical Git Security Vulnerability Announced

Comments Filter:
  • by Anonymous Coward on Thursday December 18, 2014 @07:38PM (#48630181)

    This is only an issue if you pull untrusted content, and are on a case insensitive file system. This is not typical git usage, but its a good thing to know about.

    If you do thing like pull from a repo, and run the build scrips without reading them first, you already had worse security problems, and there is nothing worse about this. It seems like the main fear would be (case insensitive) servers doing automated pulls and such getting compromised by hostile repo.

    Servers that pull from lots of git repos could spread such attacks virus style, but I really don't think many such networks of auto git pulling servers exist. More likely is a specific targeted attack against some servers, but I expect most run on case sensitive file systems.

  • Unrelated to Github (Score:5, Informative)

    by Anonymous Coward on Thursday December 18, 2014 @07:40PM (#48630201)

    I'm puzzled that Github is stated as the main actor here. They are just
    broadcasting the official announcement from the git mailing list. They are not
    involved in the initial discovery, subsequent investigations or fixes. How come
    this post end up giving them most of the credit? Have people already
    forgot that Git and Github are different entities?

    • by Anonymous Coward on Thursday December 18, 2014 @07:48PM (#48630247)

      The headline is wrong too. This isn't a Git vulnerability. This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names. That Git has a workaround for their broken behavior is good in the short run, but the correct solution would be to fix Windows and Mac OS X so that they can tell the difference between upper and lowercase letters.

      • by forand ( 530402 ) on Thursday December 18, 2014 @09:17PM (#48630719) Homepage
        You can run OS X on an encrypted case-sensitive file system without any issue. This is nota bug of windows and Mac but a bug of git allowing its own files to be overwriten because it thinks it knows better than the file system what a file is named.
      • by KingMotley ( 944240 ) on Thursday December 18, 2014 @09:49PM (#48630845) Journal

        WTF is Git? Is that a new fork of git? Cause I can't tell what you are talking about because you put the wrong case.

      • by Kjella ( 173770 )

        Tag: NOTABUG and WONTFIX. Case aware filesystems so you can have normal names and not like AUTOEXEC.BAT and CONFIG.SYS from the DOS days is great, case sensitive file systems are a really bad idea. Is there any kind of sane situation where you'd like to have two files "Config" and "config" actually coexist that isn't just begging to be confused/abused/exploited? For a marginal performance optimization all POSIX systems have shitty usability. Why am I not surprised? I guess for a server it just doesn't matte

      • by suy ( 1908306 )

        This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names.

        Odd, I thought it was exactly the opposite. Linux doesn't interpret the names at all. Only '\0' and '/' (in C/C++ notation) are treated specially by Linux in what can be allowed as file name. The rest is just an array of bytes. Is Mac OS X or Windows the ones that try (and I said try, since I'm not sure they achieve it) to protect the user from security and confusion problems. Is not just case sensitivity, think of pre-composed characters, for example (distinguishing modified+character from character alread

      • by jeremyp ( 130771 )

        No it isn't.

        Both NTFS and HFS+ are file systems that are case insensitive and case preserving (by default). They work as designed. They have always worked that way as the people who ported git to those platforms should have known.

        Just because you don't like the way NTFSD and HFS+ work and it makes the programmer's job a little harder doesn't mean there is a bug.

    • Re: (Score:1, Informative)

      by Anonymous Coward

      Have people already
      forgot that Git and Github are different entities?

      Yes. GitHub is where all the git repositories are. Not only that, Github is where all the coders are. If you don't have a GitHub profile, you don't even exist.

  • This isn't a specific git problem. It's a windows problem.

    I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file or the file tree being to deep for windows.

    • by jez9999 ( 618189 )

      I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file

      Windows' behaviour makes sense. What doesn't make sense is having Readme and readme in the same directory. What possible reason could one have for differentiating 2 files on nothing but case?

      • What possible reason could one have for differentiating 2 files on nothing but case?

        1) Programmer copies files from linux box to windows box of a certain age.
        2) Programmer makes some changes in windows land.
        3) Windows loses the case of the filenames
        4) Programmer copies files back to the same directory in linux land. Now there are two different files README and Readme.

  • No developer worth mentioning runs OS X with a case insensitive file system, and there are only 2 sets of Applications that don't work on case sensitive file systems on OS X:
    Steam - because ... well I have no fucking idea why steam doesn't support case sensitive volumes on OS X when it does so on Linux
    Adobe * - Because according to Adobe the Apple development toolchain doesn't work right and so they can't support case sensitivity ... regardless of the fact that everyone else for OS X except Adobe and Valve

    • Some developers use shared file systems on CIFS, whether Microsoft file server or Samba based. Some of us also inherit code that uses mixed case that maps to the same file name when made single case for legacy reasons: I can name several old UNIX programs that do not compile on CygWin without considerable revision of their source code, due to precisely this sort of issue.

  • by mean pun ( 717227 ) on Thursday December 18, 2014 @08:16PM (#48630409)

    Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.

    However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...

    • So does Windows, though you may confuse the Win32 API if you use it. NTFS is case-preserving and the native APIs are case-sensitive. Win32 functions can use FILE_FLAG_POSIX_SEMANTICS to require case-sensitivity, and Interix (Microsoft's POSIX-on-NT environment that runs in the Subsystem for Unix Applications or SUA) does so by default. I don't know of any way to make Win32 case-sensitive by default without doing some kind of crazy hooking of the relevant APIs or installing a filter driver to enforce it.

    • Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.

      Stepping back from HFS+ they've even supported case-sensitive file systems long before that since you could use UFS on OS X. Even OS 9 supported it but I don't remember if you could boot that from it.

      However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...

      Yep. The Adobe suite won't even open files over NFS.

  • That's no way to talk about Linus, even if he did leave his door unlocked!

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Working...