document CVE-2018-10859
This commit is contained in:
parent
22f49f216e
commit
537935333f
2 changed files with 73 additions and 32 deletions
|
@ -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,
|
||||||
|
|
|
@ -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.
|
||||||
|
|
Loading…
Reference in a new issue