mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

second vuln

Browse source
This commit is contained in:
Joey Hess 2018-06-19 17:03:04 -04:00
parent 923578ad78
commit c5166b56af
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 44 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn
View file

@ -123,30 +123,34 @@ git-annex's url downloading.
> to see if they used GETURLS. ipfs did, but not in an exploitable way.
> datalad does; looped in its developers to asess. Rest appear not to.
> TODO document this security issue in special remote protocol page
An external special remote might also make a simple http request to a
key/value API to download a key, and follow a redirect to file:///
or http://localhost/.
If the key uses a cryptographic hash, git-annex verifies the content.
But, the attacker could have committed a key that doesn't
use a hash. Also, the attacker could use the hash check as an oracle.
use a hash. Also, the attacker could use the hash check as an oracle,
to guess at the content of files.
What if an external special remote uses https to a hardcoded server (either
fully hardcoded, or configured by the user when they enable the remote),
and uses a http library that only supports https and http (not file:///).
Is that good enough? An attacker would need to either compromise the server
to redirect to a local private webserver, or MITM, and https should prevent
the MITM.
If the external special remote is encrypted, the http content is passed
though gpg. So, whatever location an attacker redirects it to would also
have to be encrypted. gpg is not told what encryption key the content is
expected to be encrypted with. (Could it be told somehow for hybrid and
shared encryption which key to use? pubkey encryption of course uses
the regular gpg public key).
This seems to require auditing of all external special remotes.
git-annex could add a new command to the external protocol, that asks
the special remote if it's been audited, and refuse to use ones that have
not.
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.
I have emailed all relevant external special remote authors a heads-up and
some questions.
So, content downloaded from encrypted special remotes (both internal and
external) must be rejected unless it can be verified with a hash. Then
content using WORM and URL keys would not be able to be downloaded from
them. Might as well also require a hash check for non-encrypted external
special remotes, to block the redirection attack. There could be a config
setting to say that the git-annex repository is not being shared with
untrusted third parties, and relax that check.
> TODO

32
doc/security/CVE-2018-10857.mdwn
View file

@ -1,24 +1,42 @@
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.
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
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.
## details
The attacker needed to have control over one of the remotes of the git-annex
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,
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).
The attacker does `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.)
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.)
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.
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