SHA1 collisions in key names was more exploitable than I thought

Yesterday's SHA1 collision attack could be used to generate eg:

SHA256-sfoo--whatever.good
SHA256-sfoo--whatever.bad

Such that they collide. A repository with the good one could have the
bad one swapped in and signed commits would still verify.

I've already mitigated this.
This commit is contained in:
Joey Hess 2017-02-24 19:54:36 -04:00
parent 27eca014be
commit 6b52fcbb7e
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
3 changed files with 10 additions and 13 deletions

View file

@ -74,13 +74,10 @@ A few other potential problems:
* `*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.
It might be worth limiting the length
The recent SHA1 common-prefix attack could be used to exploit this;
the result would be two keys that have the same SHA1.
This can be fixed by 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
@ -92,7 +89,7 @@ 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.
after the number. Could have been used in a common-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.