From d79fc1fc6fc5b8f3c0f60e1cba37c984bc5af901 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 24 Feb 2017 12:28:10 -0400 Subject: update --- ...sha1_collision_embedding_in_git-annex_keys.mdwn | 49 +++++++++++++++++----- 1 file changed, 38 insertions(+), 11 deletions(-) (limited to 'doc') diff --git a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn index c3ecde01a..013d66a1c 100644 --- a/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn +++ b/doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn @@ -14,29 +14,49 @@ git-annex backends: * SHA1 and MD5 backends are insecure because there can be colliding versions of the data they point to. -A config setting to prevent git-annex from using insecure backends would be -useful. +There could be a config setting, which would prevent git-annex from using +keys with such insecure backends. A user who checks git commit signatures +could enable the config setting when they initially clone their repository. +This should prevent any file contents using insecure backends from being +downloaded into the repository. (Even git-annex-shell recvkey would +refuse data using such a key, since it would fail parsing the key.) +The user would thus know that any file contents in their repository match +the files in signed git commits. -(git-annex might suggest enabling that configuration if commit.gpgSign -is enabled) +Enabling the config setting in a repository that already contains +file contents would be a mistake, because it might contain insecure keys. +And since git-annex would skip over such files, `git annex fsck` cannot +warn about such a mistake. + +Perhaps, then, the config setting should be turned on by `git annex init`? +Or, we can document this gotcha. + +---- A few other potential problems: +* A symlink target like .git/annex/objects/XX/YY/SHA256--foo + might be able to be manipulated to add collision data in the path. + For example, .git/annex/objects/collisiondata/../XX/YY/SHA256--foo + + I think this is not a valid attack, because at least on linux, + such a symlink won't be followed, unless the + .git/annex/objects/collisiondata directory exists. + * `*E` backends could embed sha1 collision data in a long filename extension in a key. Impact is limited, because even if an attacker does this, the key also contains the checksum (eg SHA2) of the annexed data. The current SHA1 attack is only a common-prefix attack; it does not allow creating two - colliding keys that contain two different SHA2 checksums. That would need a - chosen-prefix attack to be feasible. + colliding keys that contain two different SHA2 checksums. That would + need a chosen-prefix attack. It might be worth limiting the length of an extension allowed in such a key to the longest such extension git-annex has ever supported (probably < 20 bytes or so), which would be less than the size of the data needed for current SHA1 collision - attacks. Presumably aa chosen-prefix attack would need a similar amount of - data. Update: Now done; git-annex refuses to use keys with super + attacks. Now done; git-annex refuses to use keys with super long extensions. * It might be possible to embed colliding data in a specially constructed @@ -44,7 +64,14 @@ A few other potential problems: Need to review the code and see if such extra fields are allowed. Update: All fields are numeric, but could contain arbitrary data - after the number. Could have been used in a chosen-prefix attack - (posibly; would require field to come after key name data) or - preimage attack. This has been fixed; git-annex refuses to parse + after the number. Could have been used in a chosen-prefix attack. + This has been fixed; git-annex refuses to parse such fields, so it won't work with files that try to exploit this. + +* A symlink target like .git/annex/objects/XX/YY/SHA256--foo + might be able to be manipulated to add collision data in the path. + For example, .git/annex/objects/collisiondata/../XX/YY/SHA256--foo + + I think this is not a valid attack, because at least on linux, + such a symlink won't be followed, unless the + .git/annex/objects/collisiondata directory exists. -- cgit v1.2.3