March 1, 2017

SHA-1 collision: update for VisualSVN Server is available

The first practical collision of the SHA-1 hash function has been recently discovered and demonstrated. Researchers were able to construct two SHA-1 colliding files - the files with different content sharing identical hash value. Committing such two files with identical SHA-1 hash values will result in Subversion repository corruption caused by auxiliary data deduplication functionality. Up-to-date VisualSVN Server instances are vulnerable to this problem.

VisualSVN Server 3.5.10 hotfix patch update implements a workaround for the problem. The upgrade to the latest VisualSVN Server 3.5.10 version is highly recommended for all users. You can get the latest version of VisualSVN Server at the official download page.

How does SHA-1 collision affect VisualSVN Server and Subversion repositories

Beginning with Subversion 1.6, the repositories support representation sharing (rep-sharing) feature which provides an auxiliary deduplication for the repository content. Rep-sharing is enabled by default in repositories created with tools linked with Subversion 1.6 and later. The current rep-sharing implementation in Subversion uses SHA-1 hash function in a way that makes collisions result in repository corruption.

This problem can be considered as of medium severity by VisualSVN Server users. Firstly, the impact of the corruption is limited and isolated - the corruption makes it impossible to checkout a working copy of a repository subtree that contains one of the SHA-1 collided files. However, there will be no problems checking out other repository subtrees. Secondly, only authenticated users who have write permissions to the repositories can commit the collided files. Thirdly, there are several ways to repair the affected repository.

Another important point is that VisualSVN Server does not use SHA-1 for security purposes. All the potential problems caused by SHA-1 collision are limited to rep-sharing.

Mitigating the problem by upgrading to VisualSVN Server 3.5.10

VisualSVN Server 3.5.10 patch update includes a hotfix for the problem. VisualSVN Server 3.5.10 automatically disables representation sharing feature for all repositories and this change eliminates any possibility of corruption caused by SHA-1 collided files.

Disabling rep-sharing does not make significant performance impact and it does not affect backward and forward compatibility of the server and the repositories. It is worth noting that disabling rep-sharing does not affect any other space saving techniques in Subversion such as cheap copies and deltification. Representation sharing is going to be re-enabled in one of the next VisualSVN Server updates.

You can get the latest version of VisualSVN Server at the official download page. If you currently use VisualSVN Server 3.4.x or earlier version, please read the article KB95: Upgrading to VisualSVN Server 3.5 for upgrade instructions.

Mitigating the problem without upgrading VisualSVN Server

If you can not upgrade to VisualSVN Server 3.5.10 right now, you can prevent the corruption by disabling representation sharing feature for all your repositories manually. To disable this feature, you should edit the configuration file db\fsfs.conf (or db\data\fsfs.conf for VDFS repositories) of every repository and set the option enable-rep-sharing to false:

[rep-sharing]
enable-rep-sharing = false

How does SHA-1 collision affect Subversion working copies

Beginning with Subversion 1.7, SVN clients use SHA-1 hash function to recognize files with identical content and deduplicate them in a working copy's pristine storage. If you use an up-to-date SVN client to checkout a working copy with SHA-1 collided files, all these files will have identical content.

This problem can be considered as of low importance. The discovered collision enables generating SHA-1 collided file pairs, but the generating a file with a specific hash value is not practically possible. In other words, it is impossible that the content of a regular file will be silently replaced due to SHA-1 collision.

The problems that affect the working copies are expected to be mitigated in one of the next Subversion releases.

Other changes in VisualSVN Server 3.5.10

Comparing to the previously announced VisualSVN Server 3.5.7 update, version 3.5.10 incorporates the following changes:

Update to Apache HTTP Server 2.2.32 that provides fixes for two CVEs. These CVEs do not affect up-to-date and default VisualSVN Server installations.
Update to OpenSSL 1.0.2k that contains cumulative fixes for three CVEs. Up-to-date VisualSVN Server installations are potentially affected by CVE-2017-3732 and CVE-2016-7055. Exploiting these vulnerabilities requires a significant amount of resources and therefore the actual risks are considered to be low.

For the complete list of changes in VisualSVN Server 3.5.10 compared to version 3.5.7, see the VisualSVN Server changelog for versions 3.5.10, 3.5.9 and 3.5.8.