From 537935333f58b4120405bb15a614213fb237d72e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 21 Jun 2018 11:27:56 -0400 Subject: [PATCH] document CVE-2018-10859 --- ...hole_private_data_exposure_via_addurl.mdwn | 4 + .../CVE-2018-10857_and_CVE-2018-10859.mdwn | 101 ++++++++++++------ 2 files changed, 73 insertions(+), 32 deletions(-) diff --git a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn b/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn index f1884d8f31..ae4f6f9857 100644 --- a/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn +++ b/doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn @@ -143,6 +143,7 @@ So if the attacker knows a file that the user has encrypted with any of their gpg keys, they can provide that file, and hope it will be decrypted. Note that this does not need a redirect to a local file or web server; the attacker can make their web server serve up a gpg encrypted file. +This is a separate vulnerability and was assigned CVE-2018-10859. So, content downloaded from encrypted special remotes (both internal and external) must be rejected unless it can be verified with a hash. Then @@ -154,6 +155,9 @@ untrusted third parties, and relax that check. > TODO +Tocho Tochev has updated git-annex-remote-pcloud to not follow http +redirects. + ---- Built-in special remotes that use protocols on top of http, eg S3 and WebDAV, diff --git a/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn b/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn index 88ec3d36d2..a5bf747529 100644 --- a/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn +++ b/doc/security/CVE-2018-10857_and_CVE-2018-10859.mdwn @@ -3,52 +3,89 @@ exposure and exfiltration attack. It could expose the content of files located outside the git-annex repository, or content from a private web server on localhost or the LAN. Joey Hess discovered this attack. -Additionally, git-annex encrypted special remotes could be leveraged -by an attacker to decrypt files that were encrypted to the user's gpg +CVE-2018-10859: A malicious server for a special remote could +trick git-annex into decrypting a file that was encrypted to the user's gpg key. This attack could be used to expose encrypted data that was never stored in git-annex. Daniel Dent discovered this attack in collaboration with Joey Hess. -This was fixed in git-annex 6.20180622. +These security holes were fixed in git-annex 6.20180622. -## details +Also, some external special remotes (plugins) were improved, as a second +line of defense against CVE-2018-10857: -The attacker needs to have control over one of the remotes of the git-annex -repository. For example, they may provide a public git-annex repository that -the victim clones. Or the victim may have paired repositories with them. Or, +* git-annex-remote-pcloud 0.0.2 (thanks to Tocho Tochev) + +## attack descriptions + +To perform these attacks, the attacker needs to have control over one of +the remotes of the victim's git-annex repository. For example, they may +provide a public git-annex repository that the victim clones. Or, equivilantly, the attacker could have read access to the victim's git-annex -repository (eg on a server somewhere), and some channel to get commits into it -(eg a pull requests). +repository or a repository it pushes to, and some channel to get commits +into it (eg pull requests). -To perform the private data and exfiltration attack, the attacker -runs `git-annex addurl --relaxed file:///etc/passwd` and commits this to -the repository in some out of the way place. Then they wait for the victim -to pull the change. (As well as `file:///` urls, the attacker can use urls -to private web servers. The url can also be one that the attacker controls, -that redirects to such urls.) +These exploits are most likely to succeed when the victim is running the +git-annex assistant, or is periodically running `git annex sync --content`. -To perform the gpg decryption attack, the attacker also needs to have -control of an encrypted special remote of the victim's git-annex -repository. The attacker uses `git annex addurl --relaxed` with -an innocuous url, and waits for the user's git-annex to download it, -and upload an (encrypted) copy to the special remote they also control. -At a later point, when the user downloads the content from the special -remote, the attacker instead sends them the content of a gpg encrypted -file they wish to have decrypted in its place. Finally, the attacker -drops their own copy of the original innocuous url, and waits for the user -to send them the decrypted form of the file they earlier sent. +To perform the private data exfiltration attack (CVE-2018-10857), the +attacker runs `git-annex addurl --relaxed file:///etc/passwd` and commits +this to the repository in some out of the way place. After the victim's +git repository receives that change, git-annex follows the attacker-provided +url to private data, which it stores in the git-annex repository. +From there it transfers the content to the git-annex repository that +the attacker has access to. -The easiest exploit is when the victim is running the git-annex assistant, or -is periodically doing `git annex sync --content`. The victim may also perform -the equivilant actions manually, not noticing they're operating on the file. +(As well as `file:///` urls, the attacker can use urls to private web +servers. The url can also be one that the attacker controls, that redirects +to such urls.) -In either case, git-annex gets the content of the annexed file, following -the attacker-provider url to private data. Then git-annex transfers the content -back to the attacker's repository. +To perform the gpg decryption attack (CVE-2018-10859), the attacker +additionally needs to have control of the server hosting an encrypted +special remote used by the victim's git-annex repository. The attacker uses +`git annex addurl --relaxed` with an innocuous url, and waits for the +user's git-annex to download it, and upload an (encrypted) copy to the +special remote they also control. At some later point, when the user +downloads the content from the special remote, the attacker instead sends +them the content of a gpg encrypted file that they wish to have decrypted +in its place. Finally, the attacker drops their own copy of the original +innocuous url, and waits for git-annex to send them the accidentially +decrypted file. -This attack was fixed by making git-annex refuse to follow `file:///` urls +## git-annex security fixes + +CVE-2018-10857 was fixed by making git-annex refuse to follow `file:///` urls and urls pointing to private/local IP addresses by default. Two new configuration settings, annex.security.allowed-url-schemes and annex.security.allowed-http-addresses, can relax this security policy, and are intended for cases where the git-annex repository is kept private and so the attack does not apply. + +CVE-2018-10859 was fixed by making git-annex refuse to download encrypted +content from special remotes, unless it knows the hash of the expected +content. When the attacker provides some other gpg encrypted content, it +will fail the hash check and be discarded. + +External special remotes (plugins) that use HTTP/HTTPS could also be +attacked using the CVE-2018-10857 method, if the attacker additionally has +control of the server they connect to. To prevent such attacks, +git-annex refuses to download content from external special remotes unless +it can verify the hash of that content. + +## impact on external special remotes + +One variant of CVE-2018-10857 can exploit a vulnerable external special +remote, and could not be prevented by git-annex. (git-annex's own built-in +special remotes are not vulnerable to this attack.) + +In this attack variant, the attacker guesses at the hash of a file stored +on the victim's private web server, and adds it to the git-annex +repository. The attacker also has control of the server hosting an +encrypted special remote used by the victim's git-annex repository. They +cause that server to redirect to the victim's web server. This allows the +attacker to verify if the victim's web server contains a file that the +attacker already knows the content of, assuming they can guess the URL to +it. + +Developers of external special remotes are encouraged to prevent this +attack by not following such HTTP redirects.