add security page with current and past security holes

doc/bugs/security_hole_private_data_exposure_via_addurl.mdwn

@@ -21,10 +21,6 @@ In either case, git-annex gets the content of the annexed file, following
 the file:// url. Then git-annex transfers the content back to the
 attacker's repository.
 
-Note that the victim can always detect this attack after the fact, since
-even if the attacker deletes the file, the git history will still 
-contain it.
-
 It may also be possible to exploit scp:// sftp:// smb:// etc urls to get at
 files on other computers that the user has access to as well as localhost.
 I was not able to get curl to download from scp:// or sftp:// on debian
@@ -108,7 +104,7 @@ May have to disable use of http proxies unless
 Or better, find what http proxy is enabled and prevent using it if it's on
 an IP not allowed there.
 
-> TODO
+> done in [[!commit cc08135e659d3ca9ea157246433d8aa90de3baf7]]
 
 ----
 
@@ -122,8 +118,8 @@ in response to a TRANSFER RETRIEVE will have the same problems as
 git-annex's url downloading. 
 
 > Checked all known external special remotes
-> to see if they used GETURLS; only one that did is ipfs, which doesn't use
+> to see if they used GETURLS. ipfs did, but not in an exploitable way.
-> http so is ok.
+> datalad does; looped in its developers to asess. Rest appear not to.
 
 > TODO document this security issue in special remote protocol page
 
@@ -195,5 +191,9 @@ youtube-dl
 glacier
 
 > This special remote uses glacier-cli, which will need to be audited.
-> Emailed basak.
+> Emailed Robie Basak about it, and he looked into the http libraries
-> TODO
+> used by glacier-cli and boto. It appears that they do not support
+> file:///. It also appears that the libraries do not handle redirects
+> themselves, and that boto does not handle http redirects. glacier-cli
+> uses https. Combining all this, it seems that glacier-cli is not 
+> vulnerable to this class of attacks.

doc/news.mdwn

@@ -1,7 +1,7 @@
 [[!if test="news/*" then="""
 This is where announcements of new releases, features, and other news is
 posted. git-annex users are recommended to subscribe to this page's RSS
-feed.
+feed. Also, see [[security]] for security announcements.
 
 [[!inline pages="./news/* and !./news/*/* and !*/Discussion" rootpage="news" show="30"]]
 

doc/security.mdwn

@@ -0,0 +1,4 @@
+Information about all known security holes in git-annex, and their fixes.
+Subscribe to the RSS feed to be kept up to date.
+
+[[!inline pages="./security/* and !./security/*/* and !*/Discussion" rootpage="security" show="0"]]

doc/security/CVE-2014-6274.mdwn

@@ -0,0 +1,10 @@
+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 [[upgrades/insecure_embedded_creds]].
+
+Fixed in git-annex 5.20140919.
+
+[[!meta date="Fri, 19 Sep 2014 12:53:42 -0400"]]

doc/security/CVE-2017-12976.mdwn

@@ -0,0 +1,10 @@
+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](https://marc.info/?l=git&m=150238802328673&w=2).
+
+[[!meta date="Fri, 18 Aug 2017 11:19:06 -0400"]]

doc/security/checksum_exposure_to_encrypted_special_remotes.mdwn

@@ -0,0 +1,12 @@
+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 date="Thu, 28 Apr 2016 09:31:14 -0400"]]

doc/security/private_data_exposure.mdwn

@@ -0,0 +1,36 @@
+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.
+
+This was fixed in git-annex 6.20180622.
+
+## details
+
+The attacker needed 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.)
+
+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
+the equivilant actions manually, not noticing they're operating on the file.
+
+In either case, git-annex gets the content of the annexed file, following
+the attacker-provider url to private data. Then git-annex transfers the content
+back to the attacker's repository.
+
+This attack 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-http-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.