Submitted by From Smashing Magazine: “A few months ago, Anton Isaykin, in collaboration with the company 2comrades, found a huge vulnerability that is quite typical of big projects (we do not name names here). To test it, they obtained the file structures and even the source code of about 3320 Russian websites and some major English-language websites. Serious vulnerabilities like this aren’t supposed to exist nowadays. Every serious or visible exploit is found and fixed quickly. But here we will show you something simple and ordinary yet very dangerous.”
Its not a buffer overflow, or any real exploit of any kind like that. Its due to a bunch of idiots not understanding subversion and webservers. Its like saying Apache has a vulnerability due to its ability to display directory listings.
A serious issue? Yes.
A result of poor server management? Definitely.
But a vulnerability in SVN? No way.
This is documented behaviour. The same problem will exist if you use CVS and other version control software. You’ll get similar problems if you put any other private files onto your public web site.
This is really a training issue — people need to be made aware of how to use SVN, and how not to. But that said, it is good to have it highlighted, especially if it’s as widespread as the article seems to imply.
So I don’t see any need for any software changes in the light of this. But what would be a good idea would be for web server software to ship with recognition of common version control system files.
Web servers are already shipped to recognise file types so they can serve the right mime-types, or route them through the appropriate scripting language, etc, so it shouldn’t be hard for them to add .svn and CVS files to that recognition, and just set it not serve the content.
I have to agree, no way this is SVN’s vulnerability, but webserver misconfiguration. You can just as well drop zip archive with your passwords onto you website and cry then about zip’s vulnerability that exposed your passwords.
Denying access to stuff like .htaccess, .inc and other files and directories are the first steps those should have been taken on those servers, but they were missed – and we’ve got the “vulnerable” result.
[code]
ln -s /etc/passwd /var/www/passwd
[/code]
* submit news to osnews:
SERIOUS VULNERABILITY FOUND IN LN! OMG!!!1!11oneone
Seriously – this is what happens when every “news” site around links any news item that sounds “newsworthy” without checking the content or even trying to understand what the real issue is.
Edited 2009-09-25 16:35 UTC
This is not a vulnerability, just like the original article states:
“What was found is not actually a vulnerability because it’s documented. What we really wanted to show is that major websites and even unique services are affected.”
It’s the result of combining two pieces of software without thinking about the results.
It seems like neither “TommyCarlier” nor David Adams took the time to read or understand the article.
I really mean it. The vulnerability is in fact idiot users that copy the directory directly to their web root as part of publishing.
SVN is not really the root of the problem here, people that use SVN are usually quite tech savvy, being developers.
For people that do deployment, SVN has this functionality called export.
Just run the following command:
svn export URL-OF-YOUR-SVN-REPOSITORY-TRUNK DEPLOYMENT-DIRECTORY
Here’s a link for reference:
http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.export.html
This not a vulnerability in subversion at all… But I guess it could be called a vulnerability in the default configuration for web servers, which should block access to files started with a “.”.
http://whygitisbetterthanx.com/
This blame game is useless.
“ln -s /etc/passwd /var/www/passwd”; “serious vulnerability found in ln”: This is funny exaggeration, but that’s all. We’re talking about complex software that defies expectations (thereby “cheating” the “stupid” user), not about simple (as in 1:1 promise:deliver ratio) applications that allow one to explicitly shoot oneself in the foot.
“Its due to a bunch of idiots not understanding subversion and webservers”: Let me hijack (and revert) this point: I wouldn’t be so harsh as to call the SVN developers “a bunch of idiots not understanding subversion (…)”. I would just call them careless (and irresponsible at best). But yes, they should have added some automated checks in SVN for such grossly obvious misuses.
“The vulnerability is in fact idiot users that copy the directory (…)”: This point is unfair and rude, same as the previous one.
“It’s the result of combining two pieces of software without thinking about the results.”: This is a very good argument. Only, of course, I still wouldn’t blame the user. (See above.)
“(…) is not actually a vulnerability because it’s documented”: This is obviously bad reasoning; plus, what’s wrong with less blah-blah (posing as “documentation”) and more actual code (automated checks)? Are we teachers, self-help writers, or developers? (“Developers” is the correct answer.)
Bottom line: it actually *is* a serious vulnerability in SVN (and most probably CVS etc). I hope it gets fixed. By its developers, not by its users. Duh. Heh.