git-annex/ security

Information about all known security holes in git-annex, and their fixes. Subscribe to the RSS feed to be kept up to date.

If you have discovered a security hole and wish to report it privately, see contact.

CVE-2014-6274

CVE-2014-6274: Security fix for S3 and glacier when using embedcreds=yes with encryption=pubkey or encryption=hybrid.

The creds embedded in the git repo were not encrypted. git-annex enableremote will warn when used on a remote that has this problem. For details, see insecure embedded creds.

Fixed in git-annex 5.20140919.

[[!meta Error: Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC entries checked: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/aarch64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at (eval 11666) line 1. BEGIN failed--compilation aborted at (eval 11666) line 1. ]]

CVE-2017-12976

CVE-2017-12976: A hostname starting with a dash would get passed to ssh and be treated as an option. This could be used by an attacker who provides a crafted repository url to cause the victim to execute arbitrary code via `-oProxyCommand`.

Fixed in git-annex 6.20170818

This is related to a git security hole, CVE-2017-1000117.

[[!meta Error: Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC entries checked: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/aarch64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at (eval 11673) line 1. BEGIN failed--compilation aborted at (eval 11673) line 1. ]]

CVE-2018-10857 and CVE-2018-10859

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.

checksum exposure to encrypted special remotes

A bug exposed the checksum of annexed files to encrypted special remotes, which are not supposed to have access to the checksum of the un-encrypted file. This only occurred when resuming uploads to the encrypted special remote, so it is considered a low-severity security hole.

For details, see [[!commit b890f3a53d936b5e40aa9acc5876cb98f18b9657]]

No CVE was assigned for this issue.

Fixed in git-annex 6.20160419

[[!meta Error: Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse module) (@INC entries checked: /etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/aarch64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl-base /usr/lib/aarch64-linux-gnu/perl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at (eval 11683) line 1. BEGIN failed--compilation aborted at (eval 11683) line 1. ]]

comment 5
done
Comment by yarikoptic — Wed Oct 29 14:05:27 2025
comment 4

If you have a problem with some change that was made to fix a security hole, about the only thing you can do is file a bug report. With some really well thought out way to improve it ideally. I'm certianly not going to revert security hole fixes because some comment here complains about them.

Comment by joey — Wed Oct 29 14:05:27 2025
Another use case -- http_proxy

On some institutional servers they mandate for all http traffic to go through proxy. In our case `http_proxy` looked like `http://ptn07-e0:3128`. `datalad install` worked out but an attempt to `datalad get` a bunch of files resulted in massive list of errors, and `annex-ignore` being set for "origin" which is otherwise available. We managed to fish out that warning about security schemes and http_proxy being ignored for that reason in one of the subsequent attempts (after unsetting annex-ignore). Upon attempts to set that variable we realized that we had to provide IP instead of `http_proxy` full value or just a name (`ptn07-e0`), netmasked address (e.g. 10.0.0.1/24) also didn't work. That makes it really inflexible. Actual IP could change, without http_proxy being changed. Even the value of http_proxy could change system wide. It would be painful to require our users to adjust for that every time, and it is infeasible to demand sysadmins to somehow tune up their configuration across HPC (we have no direct connection to them). If we could at least whitelist private network -- that would provide some remedy. Regular expression, though indeed not a really security-friendly solution, could have also provided remedy. Have we missed some already existing way to make our lives easy on that system?

Comment by yarikoptic — Wed Oct 29 14:05:27 2025
comment 2

@Ilya, it seems to me you could just configure your localhost webserver to listen on one of the other localnet addresses (eg 127.0.0.2), and only serve up the "safe" files on that address. Then whitelist that address in git-annex.

That seems better than adding user-configured regexps to a security path. (Worth noting that the example regexp you gave also matches port 808, probably by accident! Regexps and security are often not the best combination.)

Also, I don't think it would be possible to implement anything that looks at the whole url in the restricted Http Manager, since the http-client library's interface does not provide the path being requested to the hook that is built on.

Comment by joey — Wed Oct 29 14:05:27 2025
comment 1

It would be good if annex.security.allowed-http-addresses could add an exception not just for any 'localhost' access, but only for URLs matching a given regexp, e.g. only for http://localhost:808?/dnanexus/file-[a-f0-9]+

Comment by https://me.yahoo.com/a/iOGTltEpmOTQ.xZ99NFP5c7Zdcc-#6a7ba — Wed Oct 29 14:05:27 2025
Comments on this page are closed.