Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

Git vulnerability with submodules

The Git community has disclosed a serious security vulnerability in Git that can lead to Arbitrary Code Execution. This has been assigned CVE 2017-1000117.

The Visual Studio Team Services (VSTS) team takes security issues very seriously.  We encourage all users to update their Git Clients as soon as possible to address this issue.

  • If you're using Git for Windows, you can download the latest version from https://git-for-windows.github.io/.
  • Visual Studio 2017 users will need to download an update when it is available later this week. Versions of Visual Studio prior to 2017 are unaffected.
  • We are also updating our Visual Studio Team Services hosted build agents with patched versions of Git, and for teams running their own agents we will provide an updated build later this week.

If you use other Git clients, please contact the vendor to understand whether or not you need to upgrade.

The problem

When fetching from remote repositories, Git URL parsing can be confused by command line options embedded inside the URL. This can be exploited to pass specific command-line options to the ssh executable, and those options may specify a command to execute using its "ProxyCommand" functionality.

For example, if you run:

git clone ssh://-oProxyCommand=notepad.exe/ /tmp/git_vulnerability

Then Notepad will open. (Substitute notepad.exe with an application of your choice if you're not a Windows user.)

Of course, since this URL looks quite funny, it's unlikely that somebody would be convinced to clone that themselves. The larger risk, instead, comes when this URL is embedded as a submodule in a rather innocent-looking repository.

An attacker can easily change the URL of a submodule in a repository by editing the .gitmodules file. If it were changed to point to the exploit URL above:

[submodule "pwned"]
path = pwned
url = ssh://-oProxyCommand=notepad.exe/

Then doing a recursive clone on this innocent-looking repository would cause arbitrary code execution.

Solution

The solution to this problem is quite simple and effective: submodule URLs are now examined more closely by Git clients. If the SSH hostname looks like a command-line option (i.e., if it begins with a "-") then the submodule is blocked. The updated Git clients referenced above contain this fix and should be installed as soon as possible.

Share the post

Git vulnerability with submodules

×

Subscribe to Msdn Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The Msdn Blogs.

Get updates delivered right to your inbox!

Thank you for your subscription

×