The following issue was fixed in Git version 2.6.1: * 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. Upstream patches: https://kernel.googlesource.com/pub/scm/git/git/+/a5adaced2e13c135d5d9cc65be9eb95aa3bacedf%5E%21/ https://kernel.googlesource.com/pub/scm/git/git/+/33cfccbbf35a56e190b79bdec5c85457c952a021%5E%21/ https://kernel.googlesource.com/pub/scm/git/git/+/5088d3b38775f8ac12d7f77636775b16059b67ef%5E%21/ https://kernel.googlesource.com/pub/scm/git/git/+/f4113cac0c88b4f36ee6f3abf3218034440a68e3%5E%21/ https://kernel.googlesource.com/pub/scm/git/git/+/b258116462399b318c86165c61a5c7123043cfd4%5E%21/ CVE request: http://seclists.org/oss-sec/2015/q4/37
Created git tracking bugs for this issue: Affects: fedora-all [bug 1269797] Affects: epel-5 [bug 1269798]
Blake Burkhart on oss-security: " 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. " Analysis: From `man git-remote-ext`: "This remote helper is transparently used by Git when you use commands such as "git fetch <URL>", "git clone <URL>", , "git push <URL>" or "git remote add <nick> <URL>", where <URL> begins with ext::. " So given a URL in format "ext::<command>[ <arguments>...]", this helper uses specified <command> to connect to a remote Git server. This was not filtered, so arbitrary command injected here leads to command execution. In order to be vulnerable, victim needs to fetch the data from attacker supplied URL without noticing. One such attack is described above. Mitigation: Avoid recursive cloning or updating of git submodules without checking the submodule URL. Non-recursive cloning is the default in git, so user needs to change this to become vulnerable ("e.g. by specifying --recursive").
git-2.5.0-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
git-2.4.3-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.1 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.5 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6.6 EUS Red Hat Software Collections for Red Hat Enterprise Linux 6 Red Hat Software Collections for Red Hat Enterprise Linux 6.7 EUS Via RHSA-2015:2515 https://rhn.redhat.com/errata/RHSA-2015-2515.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:2561 https://rhn.redhat.com/errata/RHSA-2015-2561.html
git-1.8.2.1-2.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.