Sites with .svn folders got hacked, for god’s sake people, use the ‘export’ command
3,500 websites got hacked because they had .svn folders on the live site. The really shocking thing is that Apache.org was one of the sites that got hacked:
A Russian security group has posted a detailed blog post(translation here) about how they managed to extract the source code to over 3,300 websites. The group found that some of the largest and best known domains on the web, such as apache.org and php.net, amongst others, are vulnerable to an elementary information leak that exposes the structure and source of website files. A web surfer is able to extract this information by requesting the hidden metadata directories that popular version control tool Subversion creates.
The actual ‘exploit’ itself has been well known for a long time. It is the fault of the server administrator or developer, rather than the fault of a particular application, since the working metadata directories in Subversion are only required for working copies of code. What is surprising is just how prevalent the problem is – and who it affects. Finding version control metadata directories is as simple as looking for ‘.svn’ or ‘.cvs’ folders within web paths, for example: http://www.test.com/.svn/.
For god’s sake, people, use the export command:
The Subversion Export action copies versioned files from a working copy or the repository, to another directory, allowing you to distribute the files without the .svn directory.
We’ve been using Springloops for a long time, which hosts our Subversion repositories. It has an auto-deploy feature that we rely on – every time we commit, it auto-deploys our files to our dev server. I’m fairly sure that Springloops auto-deploy feature is simply a script that hooks to the post_commit event and which then calls ‘export’ on the files you’ve just modified. I’m guessing I could write a similar script in an hour. This is the right way to deploy files from Subversion to your site. The wrong way is to treat you live site as a working copy of your repository and have it run the ‘update’ command every time the post_commit event fires. The problem with this approach is exactly what the article above describes – you can get hacked.
If you decide you absolutely need to have your site be a working copy of your repository,
the Subversion FAQ also demonstrates how to protect your site:
Add this to your httpd.conf:
# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch “^/.*/\.svn/”>
Order deny,allow
Deny from all
</DirectoryMatch>