2018-06-18 21:56:18 +00:00
|
|
|
CVE-2018-10857: Some uses of git-annex were vulnerable to a private data
|
|
|
|
exposure and exfiltration attack. It could expose the content of files
|
|
|
|
located outside the git-annex repository, or content from a private web
|
2018-06-19 21:03:04 +00:00
|
|
|
server on localhost or the LAN. Joey Hess discovered this attack.
|
|
|
|
|
2018-06-21 15:27:56 +00:00
|
|
|
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
|
2018-06-19 21:03:04 +00:00
|
|
|
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.
|
2018-06-18 18:19:58 +00:00
|
|
|
|
2018-06-21 22:16:44 +00:00
|
|
|
These security holes were fixed in git-annex 6.20180626. After upgrading
|
|
|
|
git-annex, you should restart any git-annex assistant processes.
|
2018-06-18 18:19:58 +00:00
|
|
|
|
2018-06-21 15:27:56 +00:00
|
|
|
Also, some external special remotes (plugins) were improved, as a second
|
|
|
|
line of defense against CVE-2018-10857:
|
2018-06-18 18:19:58 +00:00
|
|
|
|
2018-06-21 15:27:56 +00:00
|
|
|
* 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,
|
2018-06-18 18:19:58 +00:00
|
|
|
equivilantly, the attacker could have read access to the victim's git-annex
|
2018-06-21 15:27:56 +00:00
|
|
|
repository or a repository it pushes to, and some channel to get commits
|
|
|
|
into it (eg pull requests).
|
|
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
|
|
(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 (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.
|
|
|
|
|
|
|
|
## git-annex security fixes
|
|
|
|
|
|
|
|
CVE-2018-10857 was fixed by making git-annex refuse to follow `file:///` urls
|
2018-06-18 18:19:58 +00:00
|
|
|
and urls pointing to private/local IP addresses by default. Two new
|
|
|
|
configuration settings, annex.security.allowed-url-schemes and
|
2019-05-30 16:43:40 +00:00
|
|
|
annex.security.allowed-ip-addresses, can relax this security policy,
|
2018-06-18 18:19:58 +00:00
|
|
|
and are intended for cases where the git-annex repository is kept
|
|
|
|
private and so the attack does not apply.
|
2018-06-21 15:27:56 +00:00
|
|
|
|
|
|
|
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.
|