Hello,
further on the topic of putting in place remediation for issues that
resulted from SHA-1 collisions (CVE-2005-4900), most recently
demonstrated by material posted on shattered.io, and observed as
recoverable repository corruption on the WebKit repository:
Improving on hooks:
First thanks all fixing specific cases not covered in the original
version. As documented, it checks for the known "PDF" prefix, but is
unable to detect new collisions generated using the same method.
Code exists that performs a more general approach:
https://github.com/cr-marcstevens/sha1collisiondetection
Packaged the CLI tool for openSUSE and SUSE Linux Enterprise Server
https://software.opensuse.org/package/sha1collisiondetection
It lacks reading from stdin atm, but it could be adopted into a more
advanced hook. Any takers?
As Mark noted in his blog post, this can have a considerable performance
impact. The library claims to do what it does at the cost of less than
2x cycles.
Let's talk about how this can be applied to code. Reading
libsvn_subr/checksum.c :: svn_checksum(), the library could be dropped
there, taking over for the apr_sha1_* calls, and erroring out on the
rare detected collision. This would prevent repository corruption for
all future collisions generated using the same attack.
Performance wise, this could be optimized to restrict this to
transaction write operations.
What is really interesting about this library is that it has a
"safe-hash" mode, where upon detection of just one side of the collision
a consistently different digest will be generated. Mapping to safe
non-colliding digest values is interesting, as it would allow continued
operation of the repository, possibly the working copy. However I
imagine that there will be a number of compatibility issues on the
client and dump protocols. These would trigger in cases of legitimate
storage of one side of a collision. Do you think that this is something
worth investigating?
Andreas
Received on 2017-02-28 22:58:50 CET