Date: Mon, 12 Oct 2015 10:34:06 -0500 From: Blake Burkhart <bburky@...rky.com> To: Seth Arnold <seth.arnold@...onical.com>, oss-security@...ts.openwall.com Subject: Re: CVE Request: git On Mon, Oct 5, 2015 at 10:56 PM, Seth Arnold wrote: > The git project announced v2.6.1 https://lkml.org/lkml/2015/10/5/683 > and included the following text: > > * Some protocols (like git-remote-ext) can execute arbitrary code > found in the URL. The URLs that submodules use may come > from arbitrary sources (e.g., .gitmodules files in a remote > repository), and can hurt those who blindly enable recursive > fetch. Restrict the allowed protocols to well known and > safe ones. Thanks for sending this to oss-security. I discovered this vulnerability in git and helped get it fixed. I have included some further details on the fixed vulnerabilities. Arbitrary shell command execution from .gitmodules: Git allows executing arbitrary shell commands using git-remote-ext via a remote URLs. Normally git never requests URLs that the user doesn't specifically request, so this is not a serious security concern. However, submodules did allow the remote repository to specify what URL to clone from. If an attacker can instruct a user to run a recursive clone from a repository they control, they can get a client to run an arbitrary shell command. Alternately, if an attacker can MITM an unencrypted git clone, they could exploit this. The ext command will be run if the repository is recursively cloned or if submodules are updated. This attack works when cloning both local and remote repositories. a5adace and 33cfccb fixed this behavior by introducing a whitelist of allowed protocols for all git submodule operations. Following HTTP redirects to unsupported protocols: A separate issue that was fixed used to allow HTTP redirects to be followed to any protocol that the underlying libcurl supported. This is the default behavior of libcurl. However, git should only support a subset of the protocols that libcurl supports. For example, this allowed a git clone from an HTTP server to redirect to an SFTP server and successfully run a clone, a protocol that git otherwise doesn't support at all. Git is only supposed to support using HTTP, HTTPS, FTP and FTPS with the libcurl-based remotes, so this was unexpected behavior. 5088d3b and f4113ca fixed this behavior by limiting libcurl-based remotes to redirect to HTTP, HTTPS, FTP and FTPS, or the protocol whitelist, whichever is stricter. Circular HTTP redirects: Previously git would follow circular HTTP redirects forever. Potentially this could be used as a DoS attack if an attacker could trigger an automated fetch of a git remote. b258116 fixed this behavior by limiting git to only follow 20 HTTP redirects. > The announcement also mentions some int-based overflows but does not > describe any situations that would allow crossing privilege boundaries. Jeff King would have the full details on this. I was not involved with this. -- Blake Burkhart -- Blake
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.