Comment by fanf2 | Hacker News Reader

Comment by fanf2 | Hacker News Reader

OK, this is quite a serious vulnerability in Subversion. SVN depends more on raw file SHA1 hashes than git because git prepends a header which prevents raw SHA1 collisions from translating directly into easy svn-style repository corruption.

The reason svn is broken is its "rep-sharing" feature, i.e. file content deduplication. It uses a SQLite database to share the representation of files based on their raw SHA1 checksum - for details see http://svn.apache.org/repos/asf/subversion/trunk/subversion/...

You can mitigate this vulnerability by setting enable-rep-sharing = false in fsfs.conf - see documentation in that file or in the source at http://svn.apache.org/viewvc/subversion/trunk/subversion/lib...

This feature was introduced in svn 1.6 released 2009, and made more aggressive in svn 1.8 released 2013 https://subversion.apache.org/docs/release-notes/

SVN exposes the SHA1 checksum as part of its external API, but its deduplication could easily have been built on a more secure foundation. Their decision to double down on SHA1 in 2013 was foolish.

> this is quite a serious vulnerability in Subversion

I rather believe it's a minor bug, and that once it is fixed, they can actually keep using SHA1 as before, without having the denial of service when somebody tries. Then, for example, if somebody actually tries to put two files with the same SHA1 but different MD5 they can reject the second one before accepting it. Or they if there are two different files with same SHA1 and they accepted both and they store only one content, SVN can still continue to work. So you can't get the second unless you, for example, put it in some archive format first and then put in the SVN, OK, your problem, the SVN would still work for anything else.

In short, it sounds like a denial of service at the moment, but I think that DOS can be avoided without changing the hash algorithm.

However, I'm sure that SVN is not the only source base that was never up to now tested with two different files that have the same SHA1.

Apache Subversion developer here.

Andreas Stieger (SUSE, SVN) has written a pre-commit hook script which rejects commits of shattered.io style PDFs

https://svn.apache.org/viewvc/subversion/trunk/tools/hook-sc...

This is the first mitigation available. If you are responsible for an SVN server at risk, please make use of this hook.

If somebody could make a similar hook for Windows and post it here or to dev@subversion.apache.org that would be highly appreciated.

(edit: switched script link to HTTPS)

There have been follow-up fixes to the script and the link above is now stale. See https://svn.apache.org/viewvc/subversion/trunk/tools/hook-sc...

I didn't realise yesterday that svn also uses SHA1 for deduplicating pristine filed in its working copy. So disabling rep-sharing isn't enough to prevent broken checkouts: you need to prevent any SHA1 collisions from being committed. See the link from Stefan Sperling (stsp) to the collision rejection script elsewhere in this thread. There is more info about what they need to do to fix this from Stefan at http://mail-archives.apache.org/mod_mbox/subversion-dev/2017...

Reply on news.ycombinator.com