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.
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!).
AFAIK is the only language that automatically does bounds checking
Not by a long shot.
Python, most Scheme implementations, Haskel, ADA, and many, many languages provide similar safety features.
As you say, though, pity they're not more often used.
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
I'll post something along these lines in the next Microsoft vulnerability article and we'll see if I get modded +5 with alacrity.
I've been thinking through the dynamics of OSS. For a moment, let's forget Linux, Apache, FreeBSD and the four or five other "big guys" out there (the reason: they seem to be managed much like commercial software, in a hierarchial, closed-group fashion, just without the keeping the code a secret part).
For the vast majority of little OSS that is in so many systems, large and small, is there really any empirical proof that OSS is more secure than proprietary software? I've been wondering if it isn't possible that its even less secure.
The reason is the dynamics of programmer laziness (and I'm a programmer myself.... I know all about it). Combing through code looking for buffer overflows is tedious and repetative. How many programmers really do it all the time, every time?
I also understand the "millions of eyeballs" argument, but doesn't that really apply again to the "big guys." Does anyone really believe that literally millions of people have done detailed reviews of the myriad small programs and libraries present on a typical open source operating system?
I don't know, perhaps I'm wrong, but I'm wondering if there may not be a group-think problem here. I don't look at those tools, because everyone else is, and I'm lazy. I may poke through kernel source because it interests me, but TinyXML source does not. In a commercial environment, I make developers do it, but, except on the few big OSSes that are run basically like commerical operations, how are we really sure it is more, and not less, secure?
Sarcasm and hyperbole are the final refuges for weak minds
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)
In every commercial software house I've been in the source has been available for my review, but I wasn't given time to do it, nor was anyone else. In fact while I was allowed to read other's code, I was rarely allowed to change it, and I wasn't encouraged to suggest changes.
In open source I've read a lot of code, not just for fun, but because I'm not limited in the code I can change so I tend to change code in larger parts. That means I have to understand larger parts.
Now I'm not smart enough to have found a security flaw (yet?), but I have at least read it. Despite working 40 hours programing for years, I've found more opportunity to read other code in the open source movement. I've read some kernel code (didn't understand it), and a lot of KDE code (resulted in a few patches). I've also read code for a few other systems, but didn't get around to doing anything.
In a commercial environment, I make developers do it, but, except on the few big OSSes that are run basically like commerical operations, how are we really sure it is more, and not less, secure?
While you may be correct -- Open Source may very well be riddled with just as many bugs -- the argument shouldn't be focused on which is more secure but rather on which is more fixable. Open Source is rendered a benefit that closed source lacks: the ability to fix the source yourself. Compare the security flaws released in the last six months on sites like CERT--generally, Open Source outfits release patches much sooner than commercial counterparts. Sure, this doesn't always hold true, but Open Source grants yet another benefit: Users of Open Source are, IMO, more aware of the implications and importance of security and are thus more proactive when an exploit is discovered.
And, again, I can't stress the "fix it yourself" argument enough!
He who has no
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
Actually, 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.