Slashdot Mirror
Security Holes in CVS and Subversion Found
joe_bruin writes "News.com.com is reporting a two separate vulnerabilities that affect current versions of CVS and Subversion source control systems. Apparently, major users of these products (Linux and BSD distros, Samba, etc.) have been notified and have patched their systems." Update: 05/20 02:01 GMT by S : Clarification that there are separate issues for both CVS and Subversion.
Developers and admins have to keep security aware constantly, which is one of the hardest problems in real production environments.
Flaws drill holes in open-source databases
Geez, this is why open source needs a frickin' PR department. These flaws DRILL HOLES!!! Into Open source DATABASES!! OMGLOLWTF??!111
CVS and its pudgy cousin Subversion are not databases. They may use the *concept* of a database *internally*, but then again so do iTunes and Emacs and probably a bunch of other programs.
Does CNET not understand the concept of a version control system? Hint: only people who know what they are use them in the first place.
Regardless, I only use these things via SSH, and have never recommended running CVS with pserver or Subversion via Apache or its server, except on a well-firewalled LAN. I think that's the common practice anyway.
Pretty good rule of thumb: if you can run the service over an SSH tunnel, DO IT! Don't assume Yet Another Server Daemon is secure. Then you just have to keep an eye out for SSH exploits (which you should be doing anyway since SSH bugs are more serious than bugs in TEH OPEN-SORCE DATABASS anyway!).
because the whole idea of the "bazaar model" is to allow anyone to contribute. if your restrictions on who is allowed to do what are too stringent, interest on the part of possible developers dwindles and you'll have to all the work by yourself *g*.
;-)
apart from that, many high-profile OSS project use such an approach that only senior developers (i.e. those who have proven themselves reliable in the past) are allowed write access to the repositories. the most obvious case being the linux kernel itself, where most (if not all) patches go through the top level maintainers.
but instead of just restricting write access (which as i pointed out above can be a hinderance to OSS projects) you can introduce a slashdot-karma-like moderation that ensures that any added code was reviewed by another developer before it is "submitted" into the real repository.
anyway, by what criterium would you give out privileges to single users and restricted file sets?
managing huge OSS project is an unbelievably complex task and so far, most of the projects have proven to be pretty responsive towards security issues. but successful intrusions at debian, gnu, etc have shown that one definite draw-back of a completely open community is the risk of shipping planted, evil code!
well, time for my daily code-review
Note that this problem only exists in pserver code. Anyone using pserver on critical systems needs to reassess their security anyway.
Tarsnap: Online backups for the truly paranoid
how about: java is not Free
...). of course, this does not make it any better and in my opinion manual memory allocation is the GREATEST possible waste of a programmer's time (sensible exceptions excluded ;-).
while all these buffer overflows, etc are more than a nuissance in C/C++, many of the bugs stem from a misunderstanding on the part of the programmer (i.e. use of deprecated functions,
languages featuring garbage collection, length encoded strings, array bound checks, etc are hopefully the future, but at the moment (not least due to the lack of a free java compiler/interpreter/RE) many libraries and toolkits are still written for C/C++ and thus are also mostly used from these two languages.
java is not slow, it has a high overhead on startup!
it is just that the loading of the runtime engine, garbage collector, on-the-fly-compiling by the interpreter, etc produce a high overhead at startup. thus small, short programs seem to run slow, whereas in big applications the speed penalty is marginal!
If you knew what you were talking about AT ALL, you would not go around spouting off about a lack of free Java implementations.
Kaffe?
JikesRVM?
SableVM?
GNU Classpath?
It seems that you are writing entirely from your imagination. Either you don't know how real OSS projects work, or you misread the parent post to think it suggested a drastic change to development methods.
because the whole idea of the "bazaar model" is to allow anyone to contribute
Almost no Open Source developer allows relative strangers write-access to a CVS repository. In reality, "bazaar" development allows anyone to create changes, but it's still up to the original author (or her trusted friends, or a declared maintainer) to actually add them to the codebase. (If they refuse, then somebody can decide to fork a new project containing the desired change)
Observe how Linux works: millions of people can create changes, which they can send to one of 20 people for possible inclusion. If approved, then the patch is sent onward to the single person maintaining that kernel release (Linus, Marcello, or someone like that).
That's why it has been broadly noted that CVS is sub-optimal for managing large Free/Open projects. The one master server is too much of a bottleneck/vulnerability. Competitors like BitKeeper have arisen to try making the management of source code as distributed as writing it.
(Amusingly, BitKeeper supports OSS style development but is not itself open source)
Seriously, your solution to the problem makes the source closed to the world and only open to input from 'trusted' people. Managing the list of trusted people would be a huge job on a large project where a million code monkeys are contributing.
Oh my! Here's another poster with no idea how OSS actually works.
Guess what: there really IS a small list of trusted people, and somebody works manage which of the million possible helpers deserves to
Handling "millions" is actually a simple problem for a computer programmer. Any good coder is familiar with binary tree division, which allows you to handle lists of any size with just a few (max ~7) layers of hierarchal control.
If you want to restrict contributions to people you really trust then don't put your CVS repository on a public server.
Try this: go over to sourceforge.net, pick a random project, and add a file into the CVS tree. Good luck, you'll need it. The only way you can contribute is to convince a live human project-member that your code is worthwhile.
"and we do not know how many undetected bugs are in commercial software."
;)
Nor do we know how many undetected bugs there are in open-source software. I guess that's why they are...undetected
The most obvious reason for subversion repos is that subversion uses a small number of berkeley db files for the entire repository, so filesystem level controls may apply to the entire repository, but not individual files.
With cvs, this is possible if the filesystem uses acl's. If not, there are only the standard user, group and other categories, so there are only 3 possible access levels. Additionally, when a new file is created, the admin will have to set the permissions on these.
I believe it would be nice to build this into the control system so that a user could specify the privileges for each added file, but that would probably require the system itself to be suid to either root or some repository-specific user, which would make exploits possibly more dangerous.
Slackware has released a security update.
what, kind of like HTTP?
who the hell moderated this up? Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other. At least with a central server you only have to validate the input once.
Anon CowardActually, you can make a separate tree for the lock files. Not that hard, just check out the administrative CVSROOT directory and examine the config file (if I remember correctly). It's there in someone of the files.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
Not sure, but I think one issue is, in the Win32 world things need to be binary comp. where as in the OSS world, source comp. is enough.
If you have a vuln. in a Debian package, you do
apt-get update && apt-get -u install package
You'll see that (especially if it's a library) all kinds of other packages will automatically be upgraded
The same will not happen in the Win32-world.
New things are always on the horizon