[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP3OtXh29NEH24uO3hKyaLO9SxT-sxOTU-Yc3ksyQXjr+7YB1w@mail.gmail.com>
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.
