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
