document CVE-2018-10859

This commit is contained in:
Joey Hess 2018-06-21 11:27:56 -04:00
parent 22f49f216e
commit 537935333f
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 73 additions and 32 deletions

View file

@ -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. 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 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. 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 So, content downloaded from encrypted special remotes (both internal and
external) must be rejected unless it can be verified with a hash. Then 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 > 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, Built-in special remotes that use protocols on top of http, eg S3 and WebDAV,

View file

@ -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 located outside the git-annex repository, or content from a private web
server on localhost or the LAN. Joey Hess discovered this attack. server on localhost or the LAN. Joey Hess discovered this attack.
Additionally, git-annex encrypted special remotes could be leveraged CVE-2018-10859: A malicious server for a special remote could
by an attacker to decrypt files that were encrypted to the user's gpg 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 key. This attack could be used to expose encrypted data that was never
stored in git-annex. Daniel Dent discovered this attack in collaboration stored in git-annex. Daniel Dent discovered this attack in collaboration
with Joey Hess. 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 * git-annex-remote-pcloud 0.0.2 (thanks to Tocho Tochev)
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, ## 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 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 repository or a repository it pushes to, and some channel to get commits
(eg a pull requests). into it (eg pull requests).
To perform the private data and exfiltration attack, the attacker These exploits are most likely to succeed when the victim is running the
runs `git-annex addurl --relaxed file:///etc/passwd` and commits this to git-annex assistant, or is periodically running `git annex sync --content`.
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.)
To perform the gpg decryption attack, the attacker also needs to have To perform the private data exfiltration attack (CVE-2018-10857), the
control of an encrypted special remote of the victim's git-annex attacker runs `git-annex addurl --relaxed file:///etc/passwd` and commits
repository. The attacker uses `git annex addurl --relaxed` with this to the repository in some out of the way place. After the victim's
an innocuous url, and waits for the user's git-annex to download it, git repository receives that change, git-annex follows the attacker-provided
and upload an (encrypted) copy to the special remote they also control. url to private data, which it stores in the git-annex repository.
At a later point, when the user downloads the content from the special From there it transfers the content to the git-annex repository that
remote, the attacker instead sends them the content of a gpg encrypted the attacker has access to.
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.
The easiest exploit is when the victim is running the git-annex assistant, or (As well as `file:///` urls, the attacker can use urls to private web
is periodically doing `git annex sync --content`. The victim may also perform servers. The url can also be one that the attacker controls, that redirects
the equivilant actions manually, not noticing they're operating on the file. to such urls.)
In either case, git-annex gets the content of the annexed file, following To perform the gpg decryption attack (CVE-2018-10859), the attacker
the attacker-provider url to private data. Then git-annex transfers the content additionally needs to have control of the server hosting an encrypted
back to the attacker's repository. 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 and urls pointing to private/local IP addresses by default. Two new
configuration settings, annex.security.allowed-url-schemes and configuration settings, annex.security.allowed-url-schemes and
annex.security.allowed-http-addresses, can relax this security policy, annex.security.allowed-http-addresses, can relax this security policy,
and are intended for cases where the git-annex repository is kept and are intended for cases where the git-annex repository is kept
private and so the attack does not apply. 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.