Change Details

Until releases on August 10th 2017, Git, Mercurial and Subversion //all// mishandled SSH URIs in the form `ssh://-flag=evil/...`, and would invoke `ssh` in such a way that the domains in these URIs were interpreted as flags by SSH. From there, certain combinations of flags, like `-oProxyCommand=curl...` could cause the SSH subprocess to do materially harmful things (e.g., take over the host). **Recommended Response** These issues are complex and difficult to mitigate surgically. Generally, all installs should upgrade Phabricator, Git, Mercurial, and Subversion on the server, and Git, Mercurial and Subversion on ALL clients, immediately. See below for additional discussion. This is a rough guide for patched versions: | Software | Patched Version | Reference | |---|---|---| | Phabricator | 2017 Week 32 | | | Git | v2.14.1 | CVE-2017-1000117 | | Mercurial | v4.3 or v4.2.3 | CVE-2017-1000116 | | Subversion | v1.8.19 or v1.8.19 | CVE-2017-9800 | **Attack Description** To attack Phabricator itself with these vulnerabilities, an attacker would: - Attackers MUST have permission to create or edit repositories to execute attacks. - (Subversion Only) Create or edit a repository so it observes a safe-looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Create or edit a repository so it observes a safe-looking but attacker-controlled repository with embedded unsafe, malicious subrepository URIs. Phabricator would later clone from these URIs while executing `hg pull -u`. Currently, there is no known way that an attacker could exploit this issue against Phabricator if only Git is available on the server. To attack users (on the client) with these vulnerabilities, an attacker would: - (Any VCS) Convince a user to `clone` from an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Subversion Only) Convince a user to `checkout` from a safe looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Convince a user to `clone` a repository from a safe looking HTTP or SSH URI (`http://mercurial.evil-server.org/`), then run `hg pull -u` or other similar commands inside the working directory, triggering Mercurial to clone from malicious SSH URIs stored in subrepositories. - (Git Only) Convince a user to `clone` a safe looking repository with `--recurse-submodules`, and store a malicious SSH URI in a submodule. - (Various) Convince a user to do sketchy things with environmental variables like `GIT_SSH_COMMAND`. **Auditing** Because a successful attack could allow the attacker to execute arbitrary commands as the `daemon` user, which has access to databases and repositories, an attacker could theoretically remove all traces of a successful attack. However, an unsuccessful or imperfect attack might be identifiable with this evidence: - Look for malicious remote URIs in `SELECT uri FROM phabricator_repository.repository_uri WHERE builtinIdentifier IS NULL;` - In `/var/repo/`, look for `.hgsub` files containing malicious SSH URIs. Malicious URIs begin with `ssh://-`, and likely take the form `ssh://-oProxyCommand=...`. **More Information** For a primary source, see: - http://blog.recurity-labs.com/2017-08-10/scm-vulns See also: - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1466490.html - https://github.com/git/git/commit/4274c698f46a9bc45834c4904e7e113450c042fb The remainder of this task discusses these issues and how Phabricator is impacted in more detail.

Until releases on August 10th 2017, Git, Mercurial and Subversion //all// mishandled SSH URIs in the form `ssh://-flag=evil/...`, and would invoke `ssh` in such a way that the domains in these URIs were interpreted as flags by SSH. From there, certain combinations of flags, like `-oProxyCommand=curl...` could cause the SSH subprocess to do materially harmful things (e.g., take over the host). **Recommended Response** These issues are complex and difficult to mitigate surgically. Generally, all installs should upgrade Phabricator, Git, Mercurial, and Subversion on the server, and Git, Mercurial and Subversion on ALL clients, immediately. See below for additional discussion. This is a rough guide for patched versions: | Software | Patched Version | Reference | |---|---|---| | Phabricator | 2017 Week 32 | | | Git | v2.14.1 | CVE-2017-1000117 | | Mercurial | v4.3 or v4.2.3 | CVE-2017-1000116 | | Subversion | v1.8.19 or v1.9.7 | CVE-2017-9800 | **Attack Description** To attack Phabricator itself with these vulnerabilities, an attacker would: - Attackers MUST have permission to create or edit repositories to execute attacks. - (Subversion Only) Create or edit a repository so it observes a safe-looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Create or edit a repository so it observes a safe-looking but attacker-controlled repository with embedded unsafe, malicious subrepository URIs. Phabricator would later clone from these URIs while executing `hg pull -u`. Currently, there is no known way that an attacker could exploit this issue against Phabricator if only Git is available on the server. To attack users (on the client) with these vulnerabilities, an attacker would: - (Any VCS) Convince a user to `clone` from an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Subversion Only) Convince a user to `checkout` from a safe looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Convince a user to `clone` a repository from a safe looking HTTP or SSH URI (`http://mercurial.evil-server.org/`), then run `hg pull -u` or other similar commands inside the working directory, triggering Mercurial to clone from malicious SSH URIs stored in subrepositories. - (Git Only) Convince a user to `clone` a safe looking repository with `--recurse-submodules`, and store a malicious SSH URI in a submodule. - (Various) Convince a user to do sketchy things with environmental variables like `GIT_SSH_COMMAND`. **Auditing** Because a successful attack could allow the attacker to execute arbitrary commands as the `daemon` user, which has access to databases and repositories, an attacker could theoretically remove all traces of a successful attack. However, an unsuccessful or imperfect attack might be identifiable with this evidence: - Look for malicious remote URIs in `SELECT uri FROM phabricator_repository.repository_uri WHERE builtinIdentifier IS NULL;` - In `/var/repo/`, look for `.hgsub` files containing malicious SSH URIs. Malicious URIs begin with `ssh://-`, and likely take the form `ssh://-oProxyCommand=...`. **More Information** For a primary source, see: - http://blog.recurity-labs.com/2017-08-10/scm-vulns See also: - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1466490.html - https://github.com/git/git/commit/4274c698f46a9bc45834c4904e7e113450c042fb - http://subversion.apache.org/security/CVE-2017-9800-advisory.txt The remainder of this task discusses these issues and how Phabricator is impacted in more detail.

Until releases on August 10th 2017, Git, Mercurial and Subversion //all// mishandled SSH URIs in the form `ssh://-flag=evil/...`, and would invoke `ssh` in such a way that the domains in these URIs were interpreted as flags by SSH. From there, certain combinations of flags, like `-oProxyCommand=curl...` could cause the SSH subprocess to do materially harmful things (e.g., take over the host). **Recommended Response** These issues are complex and difficult to mitigate surgically. Generally, all installs should upgrade Phabricator, Git, Mercurial, and Subversion on the server, and Git, Mercurial and Subversion on ALL clients, immediately. See below for additional discussion. This is a rough guide for patched versions: | Software | Patched Version | Reference | |---|---|---| | Phabricator | 2017 Week 32 | | | Git | v2.14.1 | CVE-2017-1000117 | | Mercurial | v4.3 or v4.2.3 | CVE-2017-1000116 | | Subversion | v1.8.19 or v1.8.199.7 | CVE-2017-9800 | **Attack Description** To attack Phabricator itself with these vulnerabilities, an attacker would: - Attackers MUST have permission to create or edit repositories to execute attacks. - (Subversion Only) Create or edit a repository so it observes a safe-looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Create or edit a repository so it observes a safe-looking but attacker-controlled repository with embedded unsafe, malicious subrepository URIs. Phabricator would later clone from these URIs while executing `hg pull -u`. Currently, there is no known way that an attacker could exploit this issue against Phabricator if only Git is available on the server. To attack users (on the client) with these vulnerabilities, an attacker would: - (Any VCS) Convince a user to `clone` from an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Subversion Only) Convince a user to `checkout` from a safe looking but attacker-controlled HTTP URI (`http://subversion.evil-server.org/`) which would redirect to an odd-looking, malicious SSH URI (`ssh://-flag=evil/`). - (Mercurial Only) Convince a user to `clone` a repository from a safe looking HTTP or SSH URI (`http://mercurial.evil-server.org/`), then run `hg pull -u` or other similar commands inside the working directory, triggering Mercurial to clone from malicious SSH URIs stored in subrepositories. - (Git Only) Convince a user to `clone` a safe looking repository with `--recurse-submodules`, and store a malicious SSH URI in a submodule. - (Various) Convince a user to do sketchy things with environmental variables like `GIT_SSH_COMMAND`. **Auditing** Because a successful attack could allow the attacker to execute arbitrary commands as the `daemon` user, which has access to databases and repositories, an attacker could theoretically remove all traces of a successful attack. However, an unsuccessful or imperfect attack might be identifiable with this evidence: - Look for malicious remote URIs in `SELECT uri FROM phabricator_repository.repository_uri WHERE builtinIdentifier IS NULL;` - In `/var/repo/`, look for `.hgsub` files containing malicious SSH URIs. Malicious URIs begin with `ssh://-`, and likely take the form `ssh://-oProxyCommand=...`. **More Information** For a primary source, see: - http://blog.recurity-labs.com/2017-08-10/scm-vulns See also: - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1466490.html - https://github.com/git/git/commit/4274c698f46a9bc45834c4904e7e113450c042fb - http://subversion.apache.org/security/CVE-2017-9800-advisory.txt The remainder of this task discusses these issues and how Phabricator is impacted in more detail.