1871295765
Renamed annex.security.allowed-http-addresses to annex.security.allowed-ip-addresses because it is not really specific to the http protocol, also limiting eg, git-annex's use of ftp and via youtube-dl, several other protocols. The old name for the config will still work. If both old and new name are set, the new name will win.
92 lines
4.6 KiB
Markdown
92 lines
4.6 KiB
Markdown
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
|
|
server on localhost or the LAN. Joey Hess discovered this attack.
|
|
|
|
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.
|
|
|
|
These security holes were fixed in git-annex 6.20180626. After upgrading
|
|
git-annex, you should restart any git-annex assistant processes.
|
|
|
|
Also, some external special remotes (plugins) were improved, as a second
|
|
line of defense against CVE-2018-10857:
|
|
|
|
* 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 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
|
|
and urls pointing to private/local IP addresses by default. Two new
|
|
configuration settings, annex.security.allowed-url-schemes and
|
|
annex.security.allowed-ip-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.
|