Skip to content

Commit f8608ef

Browse files
frasertweedalefrasertweedale
committed
HSEC-2023-0009..0013: git-annex historical advisories
1 parent 925f6fd commit f8608ef

File tree

5 files changed

+278
-0
lines changed

5 files changed

+278
-0
lines changed

‎advisories/hackage/git-annex/HSEC-2023-0009.md

Lines changed: 46 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,46 @@
1+
```toml
2+
[advisory]
3+
id = "HSEC-2023-0009"
4+
cwe = [20, 78]
5+
keywords = ["ssh", "command-injection", "historical"]
6+
aliases = ["CVE-2017-12976"]
7+
related = ["CVE-2017-9800", "CVE-2017-12836", "CVE-2017-1000116", "CVE-2017-1000117"]
8+
9+
[[affected]]
10+
package = "git-annex"
11+
cvss = "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
12+
[[affected.versions]]
13+
introduced = "0.1"
14+
fixed = "6.20170818"
15+
16+
[[references]]
17+
type = "ADVISORY"
18+
url = "https://git-annex.branchable.com/security/CVE-2017-12976/"
19+
[[references]]
20+
type = "FIX"
21+
url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=df11e54788b254efebb4898b474de11ae8d3b471"
22+
```
23+
24+
# *git-annex* command injection via malicious SSH hostname
25+
26+
*git-annex* was vulnerable to the same class of security hole as
27+
git's **CVE-2017-1000117**. In several cases, `git-annex` parses a
28+
repository URL, and uses it to generate a `ssh` command, with the
29+
hostname to ssh to coming from the URL. If the hostname it parses is
30+
something like `-eProxyCommand=evil`, this could result in arbitrary
31+
local code execution.
32+
33+
Some details of URL parsing may prevent the exploit working in some
34+
cases.
35+
36+
Exploiting this would involve the attacker tricking the victim into
37+
adding a remote something like `ssh://-eProxyCommand=evil/blah`.
38+
39+
One possible avenue for an attacker that avoids exposing the URL to
40+
the user is to use `initremote` with an SSH remote, so embedding the
41+
URL in the *git-annex* branch. Then the victim would enable it with
42+
`enableremote`.
43+
44+
This was fixed in version **6.20170818**. Now there's a `SshHost`
45+
type that is not allowed to start with a dash, and every invocation
46+
of `git-annex` uses a function that takes a `SshHost`.

‎advisories/hackage/git-annex/HSEC-2023-0010.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
```toml
2+
[advisory]
3+
id = "HSEC-2023-0010"
4+
cwe = [200, 610]
5+
keywords = ["exfiltration", "historical"]
6+
aliases = ["CVE-2018-10857"]
7+
8+
[[affected]]
9+
package = "git-annex"
10+
cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
11+
[[affected.versions]]
12+
introduced = "0.1"
13+
fixed = "6.20180626"
14+
15+
[[references]]
16+
type = "ADVISORY"
17+
url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
18+
```
19+
20+
# *git-annex* private data exfiltration to compromised remote
21+
22+
Some uses of git-annex were vulnerable to a private data exposure
23+
and exfiltration attack. It could expose the content of files
24+
located outside the *git-annex* repository, or content from a
25+
private web server on localhost or the LAN. Joey Hess discovered
26+
this attack.
27+
28+
To perform this attack, the attacker needs to have control over one
29+
of the remotes of the victim's *git-annex* repository. For example,
30+
they may provide a public *git-annex* repository that the victim
31+
clones. Or, equivalantly, the attacker could have read access to the
32+
victim's *git-annex* repository or a repository it pushes to, and
33+
some channel to get commits into it (e.g. pull requests).
34+
35+
These exploits are most likely to succeed when the victim is running
36+
the `git-annex` assistant, or is periodically running `git annex
37+
sync --content`.
38+
39+
To perform the attack the attacker runs `git-annex addurl --relaxed
40+
file:///etc/passwd` and commits this to the repository in some out
41+
of the way place. After the victim's git repository receives that
42+
change, `git-annex` follows the attacker-provided URL to the private
43+
data, which it stores in the *git-annex* repository. From there it
44+
transfers the content to the remote *git-annex* repository that the
45+
attacker has access to.
46+
47+
As well as `file:///` URLs, the attacker can use URLs to private web
48+
servers. The URL can also be one that the attacker controls, that
49+
redirects to a URL that is accessible to the victim system (and not
50+
necessarily the compromised remote).
51+
52+
## Fix
53+
54+
The issue was fixed by making `git-annex` refuse to follow
55+
`file:///` urls and URLs pointing to private/local IP addresses by
56+
default. Two new configuration settings,
57+
`annex.security.allowed-url-schemes` and
58+
`annex.security.allowed-ip-addresses`, can relax this security
59+
policy, and are intended for cases where the *git-annex* repository
60+
is kept private and so the attack does not apply.
61+
62+
## Impact on external special remotes
63+
64+
One variant of this issue can exploit a vulnerable external special
65+
remote, and could not be prevented by `git-annex`. (`git-annex`'s
66+
own built-in special remotes are not vulnerable to this attack.)
67+
68+
In this attack variant, the attacker guesses the hash of a file
69+
stored on the victim's private web server, and adds it to the
70+
`git-annex` repository. The attacker also has control of the server
71+
hosting an encrypted special remote used by the victim's *git-annex*
72+
repository. They cause that server to redirect to the victim's web
73+
server. This allows the attacker to verify if the victim's web
74+
server contains a file that the attacker already knows the content
75+
of, assuming they can guess the URL to it.
76+
77+
Developers of external special remotes are encouraged to prevent
78+
this attack by not following such HTTP redirects.

‎advisories/hackage/git-annex/HSEC-2023-0011.md

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
```toml
2+
[advisory]
3+
id = "HSEC-2023-0011"
4+
cwe = [200]
5+
keywords = ["exfiltration", "pgp", "historical"]
6+
aliases = ["CVE-2018-10859"]
7+
related = ["HSEC-2023-0010", "CVE-2018-10857"]
8+
9+
[[affected]]
10+
package = "git-annex"
11+
cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
12+
[[affected.versions]]
13+
introduced = "0.20110417"
14+
fixed = "6.20180626"
15+
16+
[[references]]
17+
type = "ADVISORY"
18+
url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
19+
```
20+
21+
# *git-annex* GPG decryption attack via compromised remote
22+
23+
A malicious server for a special remote could trick `git-annex` into
24+
decrypting a file that was encrypted to the user's GPG key. This
25+
attack could be used to expose encrypted data that was never stored
26+
in *git-annex*. Daniel Dent discovered this attack in collaboration
27+
with Joey Hess.
28+
29+
To perform this attack the attacker needs control of a server
30+
hosting an *encrypted* special remote used by the victim's
31+
*git-annex* repository. The attacker uses `git annex addurl
32+
--relaxed` with an innocuous URL, and waits for the user's
33+
`git-annex` to download it, and upload an (encrypted) copy to the
34+
special remote they also control. At some later point, when the
35+
user downloads the content from the special remote, the attacker
36+
instead sends them the content of the GPG-encrypted file that they
37+
wish to have decrypted in its place (which may have been exfiltrated
38+
from the victim's system via the attack described in
39+
**HSEC-2023-0010** / **CVE-2018-10857**, or acquired by other
40+
means). Finally, the attacker drops their own copy of the original
41+
innocuous URL, and waits for the victim `git-annex` to send them the
42+
accidentially decrypted file.
43+
44+
The issue was fixed by making `git-annex` refuse to download
45+
encrypted content from special remotes, unless it knows the hash of
46+
the expected content. When the attacker provides some other
47+
GPG-encrypted content, it will fail the hash check and be discarded.

‎advisories/hackage/git-annex/HSEC-2023-0012.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
```toml
2+
[advisory]
3+
id = "HSEC-2023-0012"
4+
cwe = [200]
5+
keywords = ["historical"]
6+
7+
[[affected]]
8+
package = "git-annex"
9+
cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N"
10+
[[affected.versions]]
11+
introduced = "0.20110417"
12+
fixed = "6.20160419"
13+
14+
[[references]]
15+
type = "ADVISORY"
16+
url = "https://git-annex.branchable.com/security/checksum_exposure_to_encrypted_special_remotes/"
17+
[[references]]
18+
type = "FIX"
19+
url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=b890f3a53d936b5e40aa9acc5876cb98f18b9657"
20+
```
21+
22+
# *git-annex* checksum exposure to encrypted special remotes
23+
24+
A bug exposed the checksum of annexed files to encrypted special
25+
remotes, which are not supposed to have access to the checksum of
26+
the un-encrypted file. This only occurred when resuming uploads to
27+
the encrypted special remote, so it is considered a low-severity
28+
security hole.
29+
30+
For details, see commit `b890f3a53d936b5e40aa9acc5876cb98f18b9657`.
31+
32+
No CVE was assigned for this issue.
33+
34+
Fixed in *git-annex-6.20160419*.

‎advisories/hackage/git-annex/HSEC-2023-0013.md

Lines changed: 73 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,73 @@
1+
```toml
2+
[advisory]
3+
id = "HSEC-2023-0013"
4+
cwe = [312]
5+
keywords = ["historical"]
6+
aliases = ["CVE-2014-6274"]
7+
8+
[[affected]]
9+
package = "git-annex"
10+
cvss = "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
11+
[[affected.versions]]
12+
introduced = "0.20110401"
13+
fixed = "5.20140919"
14+
15+
[[references]]
16+
type = "ADVISORY"
17+
url = "https://git-annex.branchable.com/security/CVE-2014-6274/"
18+
[[references]]
19+
type = "ARTICLE"
20+
url = "https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
21+
```
22+
23+
# *git-annex* plaintext storage of embedded credentials on encrypted remotes
24+
25+
*git-annex* had a bug in the **S3** and **Glacier** remotes where if
26+
`embedcreds=yes` was set, and the remote used `encryption=pubkey` or
27+
`encryption=hybrid`, the embedded AWS credentials were stored in the
28+
Git repository in (effectively) plaintext, not encrypted as they
29+
were supposed to be.
30+
31+
That means that anyone who gets a copy of the Git repository can
32+
extract the AWS credentials from it. Which would be bad.
33+
34+
A remote with this problem cannot be enabled using `git annex
35+
enableremote`. Old versions of *git-annex* will fail with a GPG
36+
error; the current version will fail with a pointer to this web
37+
page.
38+
39+
## Remediation
40+
41+
If your repository has this problem, chose from one of these
42+
approaches to deal with it:
43+
44+
1. Change your AWS credentials, so the ones stored in the clear in
45+
git won't be used.
46+
47+
After changing the credentials, make sure you have a fixed
48+
version of git-annex, and you can then re-embed the new creds
49+
into the repository, encrypted this time, by setting the
50+
`AWS_SECRET_ACCESS_KEY` and `AWS_ACCESS_KEY_ID` environment
51+
variables, and running `git annex enableremote $remotename
52+
embedcreds=yes`.
53+
54+
2. Fix the problem and then remove the history of the *git-annex*
55+
branch of the repository.
56+
57+
Make sure you have a fixed version of *git-annex*, and force
58+
*git-annex* to rewrite the embedded creds, with encryption this
59+
time, by setting by setting the `AWS_SECRET_ACCESS_KEY` and
60+
`AWS_ACCESS_KEY_ID` environment variables, and running `git annex
61+
enableremote $remotename embedcreds=yes`.
62+
63+
Then, to get rid of old versions of the *git-annex* branch that
64+
still contains the creds in cleartext, you can use `git annex
65+
forget`; note that it will remove other historical data too.
66+
67+
Keep in mind that this will not necessarily delete data from
68+
clones you do not control.
69+
70+
3. If you're sure that you're the only one who has access to the
71+
repository, you could decide to leave it as-is. It's no more
72+
insecure than if you had used `encryption=shared` in the first
73+
place when setting it up.

0 commit comments

Comments
 (0)