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

update

Browse source
This commit is contained in:
Joey Hess 2017-02-24 12:28:10 -04:00
parent 6346704a04
commit 9de0767d0e
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
2 changed files with 41 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

6
CHANGELOG
View file

@ -33,10 +33,10 @@ git-annex (6.20170215) UNRELEASED; urgency=medium
to wget, since curl is able to display only errors to stderr, unlike to wget, since curl is able to display only errors to stderr, unlike
wget. wget.
* status: Pass --ignore-submodules=when option on to git status. * status: Pass --ignore-submodules=when option on to git status.
* Tighten key parser to mitigate against hypothetical SHA1 preimage * Tighten key parser to mitigate against hypothetical SHA1 chosen-prefix
attacks. This ensures that signed git commits of annexed files attacks. This ensures that signed git commits of annexed files
will remain secure, even against the worst possible future SHA1 will remain secure, as long as git-annex is using a secure hashing
attacks, as long as git-annex is using a secure hashing backend. backend.
-- Joey Hess <id@joeyh.name> Tue, 14 Feb 2017 15:54:25 -0400 -- Joey Hess <id@joeyh.name> Tue, 14 Feb 2017 15:54:25 -0400

49
doc/todo/sha1_collision_embedding_in_git-annex_keys.mdwn
View file

@ -14,29 +14,49 @@ git-annex backends:
* SHA1 and MD5 backends are insecure because there can be colliding * SHA1 and MD5 backends are insecure because there can be colliding
versions of the data they point to. versions of the data they point to.
A config setting to prevent git-annex from using insecure backends would be There could be a config setting, which would prevent git-annex from using
useful. 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 Enabling the config setting in a repository that already contains
is enabled) 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 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 * `*E` backends could embed sha1 collision data in a long filename
extension in a key. extension in a key.
Impact is limited, because even if an attacker does this, the key also 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 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 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 colliding keys that contain two different SHA2 checksums. That would
chosen-prefix attack to be feasible. need a chosen-prefix attack.
It might be worth limiting the length It might be worth limiting the length
of an extension allowed in such a key to the longest such extension 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 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 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 attacks. Now done; git-annex refuses to use keys with super
data. Update: Now done; git-annex refuses to use keys with super
long extensions. long extensions.
* It might be possible to embed colliding data in a specially constructed * 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. Need to review the code and see if such extra fields are allowed.
Update: All fields are numeric, but could contain arbitrary data Update: All fields are numeric, but could contain arbitrary data
after the number. Could have been used in a chosen-prefix attack after the number. Could have been used in a chosen-prefix attack.
(posibly; would require field to come after key name data) or This has been fixed; git-annex refuses to parse
preimage attack. This has been fixed; git-annex refuses to parse
such fields, so it won't work with files that try to exploit this. 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.