Linked by David Adams on Fri 25th Sep 2009 14:50 UTC, submitted by TommyCarlier
Privacy, Security, Encryption 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."
Order by: Score:
Not a svn vunrability.
by Bill Shooter of Bul on Fri 25th Sep 2009 15:14 UTC
Bill Shooter of Bul
Member since:

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.

Reply Score: 6

Alarmist headline
by spudley99 on Fri 25th Sep 2009 16:05 UTC
Member since:

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.

Reply Score: 4

RE: Alarmist headline
by morhekil on Fri 25th Sep 2009 16:23 UTC in reply to "Alarmist headline"
morhekil Member since:

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.

Reply Score: 2

Completely misinformed
by zegenie on Fri 25th Sep 2009 16:32 UTC
Member since:

ln -s /etc/passwd /var/www/passwd

* submit news to osnews:

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

Reply Score: 4

Member since:

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.

Reply Score: 2

by JAlexoid on Fri 25th Sep 2009 21:22 UTC
Member since:

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:

Here's a link for reference:

Reply Score: 1

More of a problem in the default config
by CrLf on Sun 27th Sep 2009 11:29 UTC
Member since:

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 ".".

Reply Score: 2

by diegoviola on Mon 28th Sep 2009 05:16 UTC
Member since:
Useless blame game
by rirmak on Mon 28th Sep 2009 17:24 UTC
Member since:

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. ;)

Reply Score: 1