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.
...had better get proactive :)
/. to help out its fellow OSDN member*
God knows it took them ages to get their CVS server problems resolved a few years back.
*points
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
If you compromise it, it's so broken you can't even use it to control source.
Why don't highly important OSS projects use second level protection, like only allowing X user to modify files N Y P at a file system level? If such measures where taken the worst that could happen is a DOS attack.
This also helps to sell managed code for mission critical systems.
Great, I'll grab it just as soon as the source for the patch goes into CVS! Oh wait...
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.
Just goes to show how open source leads to insecure software and the commercial software model is better.
Oh wait..thats not right...
Take 2
this just goes to show that with so many eyes viewing the software that bugs will be found and corrected, and we do not know how many undetected bugs are in commercial software.
Steal the source code? They could just download it from kernel.org...
My freedom ends where someone else's begins
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
Laugh, it's a joke.
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.
I'll post something along these lines in the next Microsoft vulnerability article and we'll see if I get modded +5 with alacrity.
But just to make things clearer here are the links to the advisories:
Subversion
CVS
I also put up a more clear description of the Subversion problem up on subversion site.
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!
In the current climate, it is just plain foolish to use a language without bounds checking in a security critical capacity.
Ironically, CVS was originally a Perl program until a C version was needed to make it real software.
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
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.
According to the alerts below, Fedora Core 2 has these vulnerabilities, and furthermore, they can lead to arbitrary code execution:
FC2 CVS alert
FC2 Subversion alert
I can understand that a buffer overflow can cause a DoS (e.g. crashing a daemon), but how can it lead to arbitrary code execution with FC2's kernel-level stack protection? Is this just a cut and paste typo from alerts of older distros?
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
Dr Hos'e may have indulged in the trollish arts in the past, but he does have a point:
how many otherwise great programmers and source control systems gurus cannot post bugfixes to CVS and Subversion codebases thanks to Bitkeeper's EULA
I've received patches from kernel developers for my open source programs. The BK licence makes them give up the right to file CVS or Subversion bug reports, in order to use BK for free.
I don't think CVS or Subversion would suit Linus's style, but maybe Arch or Darcs will in the future.
Which one happens depends on the libc and the allocation pattern, but for any app on any particular system it may be predictable.
The one that is easiest to exploit is writing over another variable, like b. This gives the attack a way to write into a variable they weren't meant to access, which leads in short order to the computer being stretched wide open.
These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.
Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.
The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.
Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.
I think you raise a really good point - hope you don't get modded down and people miss it...
I think a sizeable number of people read through source code as a way of educating themselves. OSS code is (as you point out, rightly or wrongly) seen as a source of very well-written code, and if I was going to teach myself something from someone else's source code, I'd be inclined to use OSS code as a starting point.
As these people educating themselves start to learn about what e.g. a buffer overflow is, what it looks like and how to avoid it, they'll think back to the OSS code they've read through and either mentally congratulate the author or possibly notify him/her to say their code has a security hole in it. I'm not sure: OSS code may even be used as a teaching tool in universities, in which case there will be lots of reviewers.
This reviewing-as-you're-learning approach would probably only apply to big OSS projects such as Apache or the Linux kernel I can't imagine a lot of people are suddenly going to start teaching themselves about buffer overflows using e.g. the Ethereal source. However, it's projects such as Apache and Linux that would be most at risk from buffer overflows; a buffer overflow in Ethereal, while it may be important, isn't likely to lead to lots of exploits in the real world.
Good point though - I'll be interested in what other replies you get
Just update CVS from FreeBSD whenever they apply the fix. If FreeBSD haven't made a new release yet, then you might want to turn off public access until it's fixed.
The issue has been announced via the normal announcement channels for FreeBSD and an advisory which explains what to is available. I actually got the FreeBSD advisory before I heard about it on slashdot.
Well, it's a damn good thing the *major users* are already safe. I can rest easy tonight knowing that just because I am a "Linux and BSD distro, Samba, etc.) user that I am safe.
Sorry, my sarcasm bit must be stuck.
Systems which are more fixable, or more quickly fixed (which is slightly different) present a real-world advantage.
Discovery of a vulnerability in say CVS or IIS does not mean every installation in the world will be compromised immediately. It means that the clock starts ticking. If a fix is released and applied more quickly, then there is less risk that any given machine will be compromised. Look at Schneier's "exposure envelope" model.
Historically open source has done reasonably well, though not perfectly, at releasing fixes very soon after vulnerabilities become known to the author. Open source projects tend to also be more responsive to reports, which encourages security reporters to do the right thing and report to the authors, knowing that they will get a quick response and proper credit.
There are many reports of proprietary companies sitting on vulnerabilities for more than a year. I have seen Microsoft sit on one for a couple of months. That is an enormous exposure. Being able to fix it yourself may be cold comfort but it's better than having your machines rooted.
You just made a double-fault.
Patently False
source: CVS-RCS-HOWTO
It's NOT! It's something else. irony misuse