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.

Comments

Sourceforge...

[Samah]

...had better get proactive :)
God knows it took them ages to get their CVS server problems resolved a few years back.

*points /. to help out its fellow OSDN member*

Re:Sourceforge...

[nacturation]

If they don't fix it in time, does this mean they'll be changing their name to Sourceforget?

Re:Sourceforge...

[jpetts]

If they don't fix it in time, does this mean they'll be changing their name to Sourceforget?

No, it means they'll be changing their name to ForgeSource

Re:Sourceforge...

[linzeal]

No it means they will have things like this coming up.

h4(|{3Ð b $n00p, 94nÐ4 4nÐ r3Ð 7h3 q33r. 0v3 0 m4m4 0n9 71m3!

Re:Sourceforge...

[Bingo Foo]

SCO wants their name changed to Sourceforgery.

Re:Sourceforge...

[PotPieMan]

Well, as far as I know, SourceForge uses pserver only for anonymous CVS access. Presumably, the anonymous CVS uses a read-only filesystem. If someone were to exploit this vulnerability, it would probably be pretty difficult for them to cause any problems.

Developers have access over SSH, and hopefully only have access to their project. There are obviously some concerns with malicious developers or people breaking into a developer's account, but the chances are pretty slim.

I don't think this was mentioned anywhere else, but the original annoucement includes a note about SourceForge finding a problem with the security patch breaking compatibility with some versions of WinCVS and TortoiseCVS.

Re:Sourceforge...

[Anonymous Coward]

If they don't fix it in time, does this mean they'll be changing their name to Sourceforget? Nah, after they get hacked as a result, they'll have to rename to ForgedSource.

Re:Sourceforge...

[Geekenstein]

No, if they don't fix it in time, *I'LL* change their name for them. *EEEEVVVILLLL*

Re:Sourceforge...

[mlk]

my eyes!!!

ARRrrrrrrr
*runs of, and hides from the evil*

Re:Sourceforge...

[Pharmboy]

actually, that was pretty funny. and topical to boot :p

Re:Sourceforge...

[Bill Currie]

Anonymous cvs requires write access to the tree for the lock files. Annoying but true.

Re:Sourceforge...

[Chainsaw]

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.

Re:Sourceforge...

[kVanQue]

but as most people using sourceforge for development knows the public cvstree is copy of the developer tree. (Due to this, the public cvs can be over 3 days old sometimes). So you can at most screwup the public tree, the developers will keep their source (and the screwed one will be overwritten).

Re:Sourceforge...

[Anonymous Coward]

One of the projects hosted there did so a long time ago (look at the links bottom left).

Who ever said only closed source was vunrable?

[Marxist Hacker 42]

Man- I used CVS in a project just last year. Sure hope Olivetree has patched their server.

Re:Who ever said only closed source was vunrable?

[tolan-b]

Who ever said only closed source was vunrable?

Er.. I don't think I've heard anyone except shouty 12 year olds with no clue say that.

Re:Who ever said only closed source was vunrable?

[Anonymous Coward]

Nobody. Is this the first time you've heard of a security hole in an OSS product????

Thankfully, I use Visual Source Safe

[Anonymous Coward]

If you compromise it, it's so broken you can't even use it to control source.

Just goes to show...

[georgewilliamherbert]

No amount of code review, open source or proprietary, can guarantee that there isn't some lurking bug in the application. We have probably not yet found all the ways there can be security holes, much less all the actual holes in any given thing.

Developers and admins have to keep security aware constantly, which is one of the hardest problems in real production environments.

Re:Just goes to show...

[cduffy]

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.

Re:Just goes to show...

[borgdows]

hell..even C#

Re:Just goes to show...

[The Bungi]

I'll post something along these lines in the next Microsoft vulnerability article and we'll see if I get modded +5 with alacrity.

Re:Just goes to show...

[smiff]

a language like Java, which AFAIK is the only language that automatically does bounds checking.

C and C++ are two of the very few languages which do not do automatic bounds checking. Their use should be relegated to low-level divers and OS kernels.

In the current climate, it is just plain foolish to use a language without bounds checking in a security critical capacity.

Re:Just goes to show...

[Minna Kirai]

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.

Re:Just goes to show...

[Frizzle Fry]

Please don't feed the trolls.

Re:Just goes to show...

[Anonymous Coward]

no it's not.

Re:Just goes to show...

[bladernr]

No amount of code review, open source or proprietary, can guarantee that there isn't some lurking bug in the application.

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?

Re:Just goes to show...

[harikiri]

Aren't most of the scripting languages (perl, python, ruby, tcl) secure against standard buffer overflow attacks?

Considering the speed improvements in both the interpreters for these languages, and general processors, I'm suprised more network services (smtp, web, ftp) aren't being written either entirely in these languages, or with a mixture of scripting and native C modules for the areas that need better performance.

There's a few examples that I've seen out there that already do this, like Zope and Aolserver (i think). Of course, this approach may only eliminate one type of vulnerability, and still leaves other things like these that appeared for Zope at the beginning of the year.

Re:Just goes to show...

[soulhuntre]

"I also understand the "millions of eyeballs" argument, but doesn't that really apply again to the "big guys.""

Well said - and a point many conveniently overlook. Most OSS programs pull in thousands and tens of thousands of lines of code that has been written by amateurs of questionable skill and reviewed not at all.

The fiction that OSS code is poured over by hundreds of talented eyes looking for each and every bug is a lie.

Re:Just goes to show...

[_Sprocket_]

I'll post something along these lines in the next Microsoft vulnerability article and we'll see if I get modded +5 with alacrity.

Don't you do this already? If not, you're behind the curve. MS Fanboys are quick to post this and quick to mod it up.

It's a pitty it misses the point (not that there aren't Linux fanboys missing the point too).

Re:Just goes to show...

[bluGill]

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.

Re:Just goes to show...

[Zancarius]

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!

Re:Just goes to show...

[clandestine_nova]

I actually did a small report on OSS a little while back; I'm about to fix it up for my good copy. Needless to say it's terribly written, and mostly based upon my own knowledge. However, I did come across a few of the problems you're describing.

You're right that the main problem with the "millions of reviewers" argument is that there is some question as to whether this review even happens; I personally hate reviewing my code. OSS, as it is, is either developed as a commercial product, and thus security is essential, or it is developed small-scale, where security is a very miniscule issue in comparison.

Logically, it makes sense that the more popular a piece of software is, the more it gets used and the source browsed. As well, the bugs that do get found can be fixed much faster than their commercial counterparts.

Although I've yet to see whether that argument is really true, it sounds logical to me.

Re:Just goes to show...

[Anonymous Coward]

Yes we are lazy and many of us want to have our name in the contributers list. That is the biggest reason for contributing to the code.
Debugging code is the quickest and easiest way into the contributers list.

Also when a project enters "frease" it's the ONLY way to get on the contributers list.

Having said that. The only real way to make sure the code is bug free is to make it really small.

The less code you have to manage the easier it is to see the bugs.

But you'll never make a powerful operating system in 10 lines or less.

Re:Just goes to show...

[cloudmaster]

There are several people like you, despite the people who vocally post that no one does this. I read code when I grab it, though I don't always. I'm sure that we're no the only ones who do that, though...

Re:Just goes to show...

[boots@work]

No amount of code review, open source or proprietary, can guarantee that there isn't some lurking bug in the application.

+5 insightful? More like +1, No Shit Sherlock.

Re:Just goes to show...

[Anonymous Coward]

+5, Used "Alacrity"

Re:Just goes to show...

[Anonymous Coward]

good point...

however I definitely NEVER deploy these "little programs" in any situation that would make it a risk. I *have* read some of this source code and most of it is crap.

I have never put CVS out in public, for instance. Even on our LAN, you have to use ext (SSH).

So I think people just have to use the same common sense they would with commercial software: if it's not a big name, don't expect perfection!

Besides Adobe, Microsoft, Apple, and various specific vendors in specific industries, do you see a lot of high quality software in the commercial arena?? That's why I use OSS in the first place, it may be crap, but at least it didn't cost anything.

Re:Just goes to show...

[js3]

in addition to the above, does free code used in many businesses even bother to get patched. I bet half the time once it has been installed and working everyone forgets about i

Re:Just goes to show...

[darnok]

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

Re:Just goes to show...

[sycotic]

The fiction that OSS code is poured over by hundreds of talented eyes looking for each and every bug is a lie.

I think you're missing the "all" between "that" and "OSS", because there sure are projects out there that fit your description..

Re:Just goes to show...

[Anthony Boyd]

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 have two software products, very small, that I've put out into the wild. I licensed them under BSD, so it's open source. My program PHPortfolio had a weakness in version 1.0. It only worked if installed at the top-level of a Web server. The first few people who installed my software coded up patches for themselves, and sent bug reports to me. In a later version, the thumbnailing feature was poorly done, and someone "donated" a few lines of code to improve it. So yes, the "eyeballs" argument seems to work even for small projects. Although they didn't give me their patches in every case (which is OK by the BSD license), they did give me bug reports.

I also have a program called phpBB Blog which, if you look in my forums, has a 1.0 beta out. A handful of people have downloaded it, but I've had no bug reports & no patches so far. In this case, it looks like the extra eyeballs (and there are a few) are not doing me much good. Or else the code is solid, which I doubt. :)

In any case, I think the open source model does work on a small level for small projects and it works on a big level for big projects. I suspect the only place it would fall apart is trying to tackle a big project with only a small base of support/fans. Having only a very few eyeballs scanning over a huge codebase doesn't sound like it can ensure high quality in the majority of such cases. That might need some cathedral-style development.

Re:Just goes to show...

[DerekLyons]

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.

That's a wonderful philosophical point of view, as well as way of diverting attention away from the real issue.

Managers and developers in the real world care about which is more secure. That a security hole can be quickly fixed is of little consolation when ones system is already compromised.

Re:Just goes to show...

[boots@work]

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.

Re:Just goes to show...

[boots@work]

More on this:

Why would companies react slowly? They ought to have all the capabilities of free projects, plus money. How is it possible that they perform worse?

I don't know, but I have some theories:

- Companies tend to grow bureaucracy, which prevents fast action. Open source developers can just commit the change and be done.

- Companies don't like to admit they had mistakes.

- Vulnerability reports in open source are more likely to point out where the problem is, which makes it easier to fix.

- Open source projects can draw on a lot of highly-qualified resources in the community for advice.

Re:Just goes to show...

[aardvarkjoe]

I've been wondering if it isn't possible that its even less secure.

Of course not! There are thousands of slashdot posts asserting that it's not true. If that doesn't constitute proof, I don't know what does.

Re:Just goes to show...

[Rui Lopes]

I'm suprised more network services (smtp, web, ftp) aren't being written either entirely in these languages

smtp: Apache James
web: Apache Tomcat

Re:Just goes to show...

[Seahawk]

I can only speak for myself - but the code I opensource is DEFINATELY "nicer" than the code I make at work.

Think about it - everything I opensource could be looked at by potential employers in the future - if they find some shitty code - do you think they will hire me?

Then there is the issue of pride: When I show the rest of the world what I can do, I would prefer they liked what they saw - that they respect me for it.

Both these things doesn't really matter when a PHB is telling me the deadline is in 4 hours and we REALLY REALLY need to get this stuff out the door.

On that basis alone, I would think OSS is more secure that closed source.

Re:Just goes to show...

[stevey]

Combing through code looking for buffer overflows is tedious and repetative. How many programmers really do it all the time, every time?

I don't know about programmers, but I've been Auditing Debian Packages for security holes for a good few months now.

You are correct, it's tedious, dull, and repetitive - but its nice when you get a good result.

Re:Just goes to show...

[Anonymous Coward]

I strongly urge you to actually try working in a commercial security application development, versus the freeware security world. The amount of "security through obscurity" used in the closed source world vastly, vastly outweighs the risks of "somebody else's problem" that goes on in the open source world.

Also, the time and client base available for testing a closed source application is often quite tiny, as opposed to an open source modular approach that can be robustly re-used and re-tested.

Re:Just goes to show...

[sploxx]

No. The compiler/the OS should make it possible to switch on bounds checking for C/C++ code. You would have benefits from both sides:

- code can be run fast if neccessary (local intranet where everyone is trusted)
- code can be run secure if neccessary, with switched on bounds checking.

BTW. There is bounds checking code in GCC!

Re:Just goes to show...

[JamieF]

>Why more programs aren't written in it is beyond me.

Lots and lots of programs are written in Java. The OSS community hasn't embraced Java, though, because it's not open-source.

Java also doesn't satisfy the "Lookie I can run stuff on my 486!" fetish quite as well as C does.

Based on what I've read about Perl 6 and Mono, I would say that Sun has a limited amount of time to open-source Java before the window of adoption closes as far as the open-source crowd is concerned. Obviously the tools and infrastructure stuff will have to catch up (since Java development tools and app servers etc. are generally fantastic) but I doubt that Java could last forever as an open-source product if IBM or someone of their stature started to support one of those other languages.

(Yes, I know Mono is not a language.)

Second Level security?

[Manip]

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.

Re:Second Level security?

[CajunArson]

I think SELinux could help here, but while I think SELinux is the best thing since sliced bread, it is still non-trivial to setup and configure and this has been one of its major stumbling blocks to widespread acceptance. The newer mandatory access control systems need to be simple enough for the average administrator to tackle.

Re:Second Level security?

[Delirium 21]

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?

The reason is simple. If a program is to allow any users (say, only those who are authorized to modify certain files), the program itself must have adequate permissions to modify those files. If they are system files, the program must be suid root.

Heap and buffer overflow attacks--like the sort discovered in CVS--allow unprivileged users to execute arbitrary code with the permissions of the program. Since the program itself has been hijacked, it bypasses exactly the sort of second-level protection you suggest.

Sandboxing techniques aim to counteract this by running the program in a "protected" environment, thus externalizing these kinds of checks you suggest. However, much research has shown that sandboxes themselves can be vulnerable, incomplete (think race conditions), and so on.

Security is a hard problem, and even common attack techniques are, from an algorithmic perspective, highly subtle. Simple answers often do not work.

Re:Second Level security?

[jonastullus]

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

Re:Second Level security?

[tedu]

which is why you don't run the cvs server from inetd, and instead use ssh for authentication.

Re:Second Level security?

[cujo_1111]

Is this where we can safely say that the concept of the community contributing to an OSS project has bitten OSS on the arse? j/k

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.

If you want to restrict contributions to people you really trust then don't put your CVS repository on a public server. Simple really...

Re:Second Level security?

[Minna Kirai]

Since the program itself has been hijacked, it bypasses exactly the sort of second-level protection you suggest.

But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.

(Much more important, of course, is that CVS- or any important server- be run behind a separate, simpler server handling authentication. Usually ssh)

However, much research has shown that sandboxes themselves can be vulnerable, incomplete (think race conditions), and so on.

I don't really believe that- if the sanbox boundaries are sufficiently simple, verification is managable- but it's irrelevant anyway.

A CVS server will normally only have write permission to the files making up the source code repository. A correct sandbox would give no more protection than simple file ownership (which still allows exploits if a buffer overflow occurs- if a user could insert malicious code into the source without producing the normal check-in message, she can do much mischief to all the other developers)

Re:Second Level security?

[Minna Kirai]

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)

Re:Second Level security?

[_Sprocket_]

But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.

Of course, anything that CVS or Subversion is able to write to would be data a patient attacker would like to modify.

Re:Second Level security?

[wasabii]

Additionally, why does CVS or SVN need access to WRITE to the files at all? At least the anonymous portion. For non-anonymous access, the problem goes down to how Unix programs operate. Two choices can be made: 1) the program suids to the user requesting access 2) the program does the action on behalf of the user, weither he has a local account or not.

2 should never happen. It is insecure by design.

1 is preferable. Access happens as those needing access, system level. 1 however, for traditional Unix, requires the process to have root access to suid. This is unacceptable. Windows NT programs do not need Administrator access to conduct operations on behalf of a user, they just need that user's crediantials, which are passed to a trusted subsystem, and that subsystem grants the system the permissions neccassary. The OS doensn't trust the software. (I am in no way saying that Windows is "more secure", im just saying that in this particular example, it has the potential to be more secure, cleaner, and easier.)

What Unix really needs is a new way to suid. I would say it would work like this: The program passes the username/password the user sent to another component, which is out of process. Such as a daemon, or maybe kernel level. That other process uses the local system configuration to make a determination weither or not the CVS daemon should be able to conduct operations on the user's behalf, and grants only those permissions needed to a certain context, even involving a time frame if neccassary. The program does the actions, and then "releases" the access.

That's how It Should Be.

Re:Second Level security?

[Minna Kirai]

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.

Re:Second Level security?

[Rick and Roll]

Security is a hard problem

P class or NP class?

Re:Second Level security?

[Gilk180]

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.

Re:Second Level security?

[arch_helmet]

Parent is +3 Insightful?? WTF?
This is a math joke...and not a bad one. I moderate +i, Funny.

Re:Second Level security?

[Anonymous Coward]

People are doing insightful mods so karma goes up. +i Funny doesn't, and if you get modded down, your karma goes down.

Re:Second Level security?

[mec]

That's right. In November 2003, there was an unsuccessful Trojan-CVS attack on the Linux kernel.

Linux kernel development process thwarts subversion attempt

The attack failed because, basically, the CVS repositories for the linux kernel are not the real source trees -- they are just mirrors of people's bitkeeper trees.

And here is a Trojan FTP attack. Of course CVS and FTP are different protocols, but the idea is similar -- inject malware into the OSS development stream.

Re:Second Level security?

[Anonymous Coward]

So in the future people will try to karma whore themselves into write access on big projects:)

BTW: I believe that Debian has fixed the CVS bug yesterday. http://www.debian.org/security/2004/dsa-505

Re:Second Level security?

[dossen]

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 the tree is binary you get log(n) layers. So for seven layers you have at most 2^7 = 128 leafs.

Re:Second Level security?

[Anonymous Coward]

This is a math joke...and not a bad one. I moderate +i, Funny.

No, slashcode doesn't support imaginary numbers.

Thank you, thank you... I'm here all week.

Re:Second Level security?

[mill]

..and how many projects work like Linux?

http://web.mit.edu/ghudson/thoughts/bitkeeper.wh yn ot

Re:Second Level security?

[Anonymous Coward]

Hiya. I have Fedora Core 2. Selinux is working fine here with no configuration at all.

Re:Second Level security?

[JamieF]

>by what criterium would you give out privileges to single users and restricted file sets?

Well, I wouldn't use any race involving many laps around a short track at all.

The singular of "criteria" is "criterion".

Great!

[Psychor]

Great, I'll grab it just as soon as the source for the patch goes into CVS! Oh wait...

Re:Great!

[bladernr]

CVS: Putting the "Open" back in "Open Source Software"

open source databases??

[Anonymous Coward]

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

Re:open source databases??

[bruthasj]

CVS and its pudgy cousin Subversion are not databases.

CVS uses RCS as a back-end store. Subversion uses Berkley DB as a back-end store.

Re:open source databases??

[damiam]

Evolution also uses Berkley DB as a back-end store. Slashcode uses MySQL. That doesn't make them databases. They are an email client and a CMS, respectively. CVs and SVN are both version control systems, not databases, whether or not the use databases on the back end.

Re:open source databases??

[shird]

"CVS repository."

repository
1. See data dictionary.
2. The core of a CASE tool, typically a DBMS where all development documents are stored.

Shit, seems like calling it a '..source database' isn't too far off the mark for a news outlet. Better than 'the fabric of the internet' or something gay.

give these guys a break.

Re:open source databases??

[shird]

that should have read:

repository
1. /database/ See data dictionary.
2. /programming/ The core of a CASE tool, typically a DBMS where all development documents are stored.

Re:open source databases??

[Minna Kirai]

CVS uses RCS as a back-end store.

Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active. But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".

Re:open source databases??

[tumbaumba]

They may use the *concept* of a database *internally*, but then again so do iTunes and Emacs and probably a bunch of other programs.

I concur about emacs. Not only it is a database but it can also do this and that. Now if only I could make my emacs to brew coffee.

Re:open source databases??

[antic]

Which leads me to wonder -- is there a freelance PR business, specialising in open source software and available to work from afar (effectively contract tele-commuting), serving the OSS market?

Someone/group that would volunteer or work on a nominal per-hour fee to get well-worded and accessible info out to the masses?

If there isn't, it sounds like there might be an opportunity out there for groups smaller than someone like RedHat, IBM, Sun, etc...

Re:open source databases??

[sproket]

The problem here is that a fundemental practice of open-source is to allow anonymous access to development sources. You can't provide anonymous cvs or subversion access through ssh.

Re:open source databases??

[florist]

Now if only I could make my emacs to brew coffee.

you can. there is a coffee.el package
http://list-archive.xemacs.org/xemacs-beta/199909/ msg00368.html

Re:open source databases??

[Anonymous Coward]

. Now if only I could make my emacs to brew coffee.

I've got a VIM script which you could convert.

Re:open source databases??

[Anonymous Coward]

If, say, my boss hits that and reads "drills holes in open-source databases" the first thing that will pop into his head is: "oh shit, our open-source MySQL server has been hacked! Get this open source crap off our systems ASAP and go back to the warm happy comfort of SQL server!"

I guess they could've said "open-source *source database*" but that would be confusing. Maybe they should just say "popular source-code distribution servers" instead of mentioning open source or databases at all!!

These are the same outfits who also call Windows viruses "computer viruses" which means I again have to explain to my boss what they /really/ mean.

Re:open source databases??

[Dahan]

You can't provide anonymous cvs ... access through ssh.

Demonstrably false.

Re:open source databases??

[Omnifarious]

From what I've seen, it's fairly common to provide access to Subversion repositories through Apache. Apache has SSL support built right in, and the only means of doing really sophisticated permissions management on your repository is with Apache.

Re:open source databases??

[bruthasj]

Whatever. They use it. Linux uses SSH, but that doesn't make it a secure system.

Re:open source databases??

[bruthasj]

Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active.

Sorry, meant to say RCS format plain text files.

But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".

Database

I do not agree with you. Just like I wouldn't agree if you said filesystems weren't databases. For crying out load, my blog is a database!

Re:open source databases??

[Minna Kirai]

Database

Did you even read the definition you linked to? Apparently not, so I'll paste it here: "A collection of data..." "...sets of persistent
data..." According to that page, "databases" aren't programs at all- they're only the files (data) that the software handles. So by that definition, even Oracle isn't a database (although it handles them)

For crying out load, my blog is a database!

The word "is" isn't equivalent to "has". By claiming your blog "is a database", you are saying that it is just a pile of data, and has no functional features.

Or alternatively, you have defined the word in such a generic way that all software is a database, which robs "database" of any informational content.

Or how about this: Would you say your blog "is an operating system?" After all, it's a "system" of some kind, and it "operates"...

Re:open source databases??

[hacker]

You're kidding, right? Here are their instructions for setting up anonymous cvs-over-ssh:

To use anoncvs over ssh, remove the ':pserver:' prefix on the cvsroot, and set the variable CVS_RSH to 'ssh', using the method appropriate for your shell.

Of course, as you know that simply won't work, because the user 'anoncvs' will not exist as a valid user on the server-side. Go ahead, try it on any box running an existing pserver instance.

Do you have a real, measurable example of anonymous cvs-over-ssh, or are you just taunting the original poster?

Re:open source databases??

[Dahan]

Quit trolling. Why don't you follow the nice instructions I linked to if you want a real, measurable example of anonymous cvs-over-ssh?

Re:open source databases??

[hacker]

I found better instructions, which interleaved more closely with the way we do business on our Free Software project hosting services.. in a slightly more secure fashion. The added benefit is that we also now can offer anonymous cvs-over-ssh, cvs-over-ssh, pserver (which is quite secure, despite the FUD to the contrary), and subversion repositories to our project developers.

But thanks anyway for pushing me to find alternatives that actually work.

Re:WTF???

[jafomatic]

Of course not. We're all looking to see if we need to update or patch something.

Good news for Samba...

[NEOtaku17]

"The Samba Project, which maintains file server software that integrates with Microsoft Windows networks, uses Subversion. However, the project's developers were warned about the security issue before it was made public, Esser noted."

- By Robert Lemos Staff Writer, CNET News.com

Re:Good news for Samba...

[Anonymous Coward]

Yeah, I love that. Because Samba's SVN server is more important than mine.

Yes, yes, I know. Samba is installed on millions of computers and a backdoor inserted in the source would be a nightmare. But the exploit is to execute code on the SVN server.

Feels like high school all over again -- my project's more popular than yours, so I get notified of potentially disasterous exploits first! Woohoo! Don't you worry now, it's not like the black hats have probably had this exploit for weeks now.. oh wait.

uh oh!

[L0stm4n]

hopefully no evil hax0rs use this to steal the source code of linux! ( I know it in't in a cvs but it has a cvs gateway )

Re:uh oh!

[GregAndreou]

Steal the source code? They could just download it from kernel.org...

Re:uh oh!

[damgx]

You know what happens if you steal from Santa right?

You go on his "bad" list. And as Linus says: Don't mess with penguins.

Re:uh oh!

[Anonymous Coward]

Look! In the sky! What is that?

Oh.. it's the original posters joke flying over your head.

Re:uh oh!

[Bull999999]

I already did that because I'm a L33T HAX0RS yo!!! In fact, I just download your post into my SUPA L33T computer's harddrive, in a L33T folder called cache, using a super secret L33T NinJas technique.

Aren't all "First Post" posts Offtopic?

[Anonymous Coward]

From the FAQ:

""First Post" comments are one of those odd little memetic hiccups that come out of nowhere and run amok. Basically, people with altogether far too much spare time sit and reload Slashdot, hoping that they will get the "First Post" in a discussion. This is one of those things that the moderation system was designed to clean up, and for the most part, it works. "First Post" comments usually get moderated down as off-topic almost instantly."

Backdoors in our projects

[Anonymous Coward]

Hmm, so does this mean that we need to go looking for backdoors in every piece of code out there that uses a publicly visible CVS tree? Better get started!

Re:Backdoors in our projects

[AHumbleOpinion]

[satire]You mean people were not doing this already? That they are just blindly recompiling whatever they get? So much for the million eyeballs argument from OSS advocates.[/satire]

Re:Backdoors in our projects

[TheLink]

Personally the million eyeballs argument always sounded like the infinite monkeys writing Shakespeare argument.

You need brains not eyeballs. Or infinite eyeballs not a million (chance that one eyeball mutates into uberhacker).

Re:Backdoors in our projects

[_Sprocket_]

Yeah. I'm much more trusting of the million eyeballs being applied to my proprietary vendor's application.

Re:Backdoors in our projects

[aardvarkjoe]

Why is it that whenever somebody mentions a flaw in open source, there are always a million slashbots that jump up to say "well, proprietary software's no better!" Pointing fingers makes you look like four-year-olds.

Re:Backdoors in our projects

[_Sprocket_]

Why is it that whenever somebody mentions a flaw in open source, there are always a million slashbots that jump up to say "well, proprietary software's no better!" Pointing fingers makes you look like four-year-olds.

Pot, kettle, black.

PR department you say?

[Samah]

As mentioned in a previous comment, perhaps there DOES need to be some kind of PR department for open source.
Perhaps a group of dedicated OSS developers needs to form some kind of committee to produce non-biased articles re: open source, and pass those on to the media.
Think about it - it could work, and if it was committee-based, unbiased views could be maintained.
Factual (rather than MS-funded/manufactured) data could be used to generate anti-FUD articles which, if advertised/promoted correctly, could reveal to the public some of Microsoft's baseless attacks in the name of profit, and could sway the masses' views of OSS in general.

Re:PR department you say?

[jonastullus]

it certainly is a nice idea and i am all in favor of it. but wouldn't this become just the antagonist of microsoft's efforts to slander OpenSource?
wouldn't this soon become an institution for companies like IBM, Novell, HP, SuSE, RedHat, ... to voice their own propaganda and TCO-FUD?

while unbiased information is always a good thing, it can only be achieved by a knowledgeable yet uninvolved person or group and how exactly is such a thing to occur with OpenSource?

in my opinion, it would be nice to have a more or less official institution releasing OpenSource/FreeSoftware related news to the news agencies to prevent obviously false and erroneous headlines. but to think that such an institution would abstain from propaganda and biased assessments is naive!

Re:PR department you say?

[murdocj]

Perhaps a group of dedicated OSS developers needs to form some kind of committee to produce non-biased articles re: open source

Am I the only one who sees a bit of a contradiction here?

Re:PR department you say?

[Ruie]

ESR used to do this, but it looks like he is looking for a replacement

Re:PR department you say?

[bladernr]

... to form some kind of committee to produce ...

There is a reason no one has ever built a statue to a committee.

Re:PR department you say?

[Frizzle Fry]

Perhaps a group of dedicated OSS developers needs to form some kind of committee to produce non-biased articles

Wow. I've never actually said "you must be new here" to someone on slashdot and have always hoped that it would never be necessary. But your claim that "dedicated OSS developers" know how to be "non-biased" is making it rather difficult.

Re:PR department you say?

[Anonymous Coward]

ESR represents all that is fucked up in the OSS world.

Re:PR department you say?

[Samah]

By "dedicated" I don't mean people who are dedicated to writing OSS, I mean people are dedicated to do something about the misinformed slander thrown about by some institutions (ie. AdTI).
Anyone in the development community who wishes to see OSS given a decent moral chance rather than be trodden on by companies with money to waste (ie. Microsoft) on "years of extensive research" into why OSS sucks, would have the ethics to give a non-biased view. Even if there were the occasional overly biased article produced (probably unavoidable), that's the point of a committee, and editors.
Read between the lines next time please.

Re:PR department you say?

[Anonymous Coward]

Rodin did. sort of. http://www.ibiblio.org/wm/paint/auth/rodin/burgher s.jpg

Another security flaw found

[Canberra Bob]

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.

Re:Another security flaw found

[thebatlab]

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

Re:Another security flaw found

[DerekLyons]

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.

We also do not know how many undetected bugs and vulnerabilities lay hidden in any arbitrary piece of OSS software. That these are (in theory) easily fixable does not change the fact of their existence.

Re:Another security flaw found

[FooBarWidget]

But all known vulnerabilities for open source software is published. Contrast to commercial software: you only know what the company tells you. I wouldn't be surprised if a company hides thousands of bugs.

If CVS was implemented in Java...

[StLawrence]

If CVS was implemented in Java it couldn't suffer from this
kind of problem. Sure, there are still plenty of other bugs
that can be coded up in Java, but not nearly the plethora of
agonizing painful excruciating unfindable bugs you can
subject yourself (and your users) to with applications written
in C & C++ and other archaic languages.

I'm sure there are good reasons to program in C, C++,
assembly language, FORTRAN, COBOL, BASIC, ... I just
can't think of any offhand. :-)

Re:If CVS was implemented in Java...

[jonastullus]

how about: java is not Free

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

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.

Re:If CVS was implemented in Java...

[cduffy]

Java, or any of the other myriad of safe languages out there right now -- they're not exactly rare.

I think it's a little unkind to refer to C as archaic -- it still most assuredly has a place; that place just isn't doing application-level development. Someone has to maintain your JVM, for example, and Java quite certainly isn't the language to do it in.

Re:If CVS was implemented in Java...

[burcarpat]

actually, this particular problem is apparently due to the use sscanf function, which is c rather than c++. c++ can not save you if you insist on using facilities retained to ensure c compatibility

in the future, may be you should read the reason of the defect before claiming things like this...

-- ba

Re:If CVS was implemented in Java...

[jonastullus]

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!

Re:If CVS was implemented in Java...

[Anonymous Coward]

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?

Re:If CVS was implemented in Java...

[grungeKid]

According to the article, the hole in Subversion was "caused by an error in the way the code parses dates". Now, incorrect date parsing is just as easy to do in Java (or C# or Python or any non-memory-managing language) as it is in C/C++. I haven't read more detailed information about the Subversion hole, but if you think you're safe just because you're programming in a language/environment where buffer overflows can't happen, you've got another thing coming.

Re:If CVS was implemented in Java...

[fishdan]

Your post actually raises some interesting issues, but you will almost certainly be modded as flamebait because of your silly petty comments about older languages. There really are no bad languages, only bad developers. Except for Scheme -- it sucks (kidding!!)

There is some merit to talking about some mission critical programs being moved to java, but of course you have to recognize that VM's are vulnerable to all sorts of hacks.

I do think that java probably is preferable as a language for avoiding buffer overflow vulnerabilities, especially for less experienced developers. It will be interesting to see how James will stack up with the notoriously holy (pun intended--damn I crack myself up) Sendmail. There ARE other examples of java in critical situations, I'm sure -- but none spring to mind.

I do constantly use java to write the shell stuff that I know someone is going to bang on -- just because I haven't seen a root exploit from a java process yet.

Re:If CVS was implemented in Java...

[Anonymous Coward]

> Someone has to maintain your JVM, for example, and Java quite certainly isn't the language to do it in.

JikesRVM is written in Java.

Re:If CVS was implemented in Java...

[pHDNgell]

Java isn't magic here. There's also ocaml, haskell, erlang, python, and countless other languages that prevent fatal accidents while still being very pleasant to use. OCaml, in particular, would probably yield a faster, safer CVS.

Re:If CVS was implemented in Java...

[Rick and Roll]

Yeah, I agree with you there. Probably in fewer lines as well.

I think a JIT compiler written in ocaml would be cool. I hear ocaml is an excellent language for writing compilers.

Re:If CVS was implemented in Java...

[Cthefuture]

I agree that O'Caml is pretty good. However, it has some serious flaws holding it back.

One is that it suffers from an absolutely horrible default syntax. Erlang and the original SML that O'Caml is derived from present a much more sane syntax. Yes, you can change the syntax but no one wants to add that confusion!

Another is that O'Caml suffers from academia syndrome. Too many absolutely useless and/or confusing features and too much optimization for the least used cases. A common problem with inexperienced developers, academics, engineers pretending to be programmers, and/or other ivory tower builders.

Cyclone (a "safe" extension to C) is another project that could have been really great but was run into the ground by academic foolishness.

Re:If CVS was implemented in Java...

[cduffy]

JikesRVM is written in Java.

Yes, but it's a research VM. That's a horse of an entirely different color.

Re:If CVS was implemented in Java...

[Anonymous Coward]

Yes, it is a research VM, but it's fairly advanced (several JIT's, runs pretty fast, etc. etc.). My opinion is simply that there's nothing stopping you from writing a maintainable and secure JVM in Java, even if Jikes itself is not secure at the moment. I'd be interested to hear what does make Java a bad choice for a VM implementation though, from your perspective.

Re:If CVS was implemented in Java...

[Anonymous Coward]

If CVS was implemented in Java we would still be checking in version 0.1 of the sourcetree

Re:If CVS was implemented in Java...

[jonastullus]

If you knew what you were talking about AT ALL, you would not go around spouting off about a lack of free Java implementations.

from their respective web sites:

kaffe:
Kaffe is constantly under development, and lacks compatibility in many ways with the current releases of Java. It lacks many key features of a full Java virtual machine implementation - including security related features such as a complete bytecode verifier essential for running untrusted code.

jikesrvm:
Jikes RVM can run many, but not all Java programs. The Classpath libraries, which Jikes RVM uses, currently does not provide a complete Java implementation; Swing and AWT coverage is particularly incomplete. Jikes RVM also currently does not support other features such as bytecode verification.

sablevm:
SableVM is able to run many applications and benchmarks, including multi-threaded programs, but it is limited by the current state of the class libraries, and occasionally lacks VM support for some class library features.

gnu classpath:
Not all classes and methods are implemented yet, but most are.

why be so rude to assume that i have NO PLAN AT ALL??? i do know about the free java implementations, but according to themselves they are (not yet) a complete alternative to the sun java jre. surely you can develop java projects under them, but you can't neccessarily run all code written for the sun JRE.
sun's java itself is most certainly NOT FREE (as in speech), which is all i said!. and the fact that after many years there are alternative implementation getting ready, does not refute the fact that in the past there weren't!

why be such a smartass? you know perfectly well that java's non-free-ness is a problem especially among the followers of the Free Software movement (which is also why so much energy has been put into writing alternatives).

Re:If CVS was implemented in Java...

[t_allardyce]

ah like my ass? that too has a high overhead on startup, but once it gets going the shit comes out full throttle!

Re:If CVS was implemented in Java...

[DimGeo]

At our company we are often targetting JDK 1.1.8, and Kaffee supports most of that. It is entirely possible to use those features to write just about anything you need for a decent CVS server implementation. Sure, nio, and some nice new container classes are gone, but Hashtable and Vector are there, and you have java.io, which is OK for many programs.

Re:If CVS was implemented in Java...

[MemoryDragon]

Ahem, no date parsing is close to impossible to be screwed up in java, there have been functions for this kind of thing since jdk 1.2 which has been out since 99 or so.

Re:If CVS was implemented in Java...

[Anonymous Coward]

I'm glad that my comment caused you to look at their websites.

What you said was "java is not free", in response to a suggestion that Java be used to write CVS, and from this I guessed that you did not really know what you were talking about. These VM's are all mature enough to run a Java-only CVS. Mostly Classpath is lacking with respect to the graphical stuff, but even that is coming along. Yes, the security stuff is also lacking, but if some group cared enough, it wouldn't be impossible to write a bytecode verifier either -- there are no "secrets" as to how verification is supposed to be done. Even still: it's possible to use the Sun verifier to verify classfiles and then run them on one of these VM's, as a stop-gap solution.

The problem is, when you say, "Java is not free," uninformed people will think that Java itself is a bad choice of language because the official Sun implementation is non-free. That's just not true, because we have these other viable alternatives. In fact, in my opinion, it's also fairly untrue even without these viable alternatives: I've seen many worthwhile free software projects written for the Sun JDK's, and I would also trust a CVS written for the Sun JDK (although of course I would prefer it to run a free VM).

Please, respectfully: spend more time on your projects, instead of writing things about which you are relatively uninformed on Slashdot and confusing others. Do you see hackers on these VM's bitching day-in and day-out on /. about Java not being free? No, they just get on and do their thing.

Re:If CVS was implemented in Java...

[vrai]

One of the nice things about CVS is that it'll run on just about anything - and C is much more portable than Java. There are C compilers for pretty much anything with a processor, Java is limited to a small subset of these (due to its higher overheads).

Also C and C++ are no more archaic than Java or .NET. They simply require a higher level of skill to work with safely. There is absolutely no excuse for suffering buffer overflows in C/C++. They occur because people seem to think they can program C like it's BASIC. Note that these same programmers will produce code that is bug ridden, unsafe and slow regardless of what language they use.

Is it the same flaw?

[Anonymous Coward]

I'm confused. I thought SVN was a rewrite of CVS...? Is the flaw based on a common library or something? Puzzled.

Re:Is it the same flaw?

[breser]

No whoever submitted the article to Slashdot was confused. If you read the news.com article carefully it is clear that they're separate issues.

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.

Re:Is it the same flaw?

[Eric Smith]

They are totally unrelated flaws.

pserver only

[cperciva]

Note that this problem only exists in pserver code. Anyone using pserver on critical systems needs to reassess their security anyway.

Re:pserver only

[arkanes]

You mean like sourceforge? Anonymous CVS access is a pretty import thing to alot of projects.

Re:pserver only

[Anonymous Coward]

Don't run the pserver on the machine with the writable repository. It's like keeping some primary database on the same machine as your public web server, one just shouldn't take that risk.

Re:pserver only

[cperciva]

You mean like sourceforge?

I'm quite happy with saying that SourceForge should reassess their security.

Anonymous CVS access is a pretty import thing to alot of projects.

There are much better options; CVSup and rsyncing tarballs are probably the best.

Re:pserver only

[kryptkpr]

I'm quite happy with saying that SourceForge should reassess their security.

Do you actually run projects at SourceForge? You have to use a ssh tunnel to be able to write to any project repository.

Re:pserver only

[Minna Kirai]

There are much better options; CVSup and rsyncing tarballs are probably the best.

They certainly aren't! Well, CVSup is OK (although most of it's advantages over straight CVS are just implementation details, which could be added to CVS is someone cared enough)

But rsyncing tarballs is just horrible. It's not powerful at all- it can only supply access to the very latest version of the files, while interested power-users may validly desire older or tagged revisions.

That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.

Re:pserver only

[boots@work]

That's bad in general, but there's also a specific legal limitation to it: If the source code is GPL, and the project releases precompiled executables, then they are obliged to provide the exact source code version used for that executable. This is trivially accomplished with CVS, but rsync alone is inadequate.

Wow, fascinating point. I can imagine that some of the well-intentioned sites providing binaries of prereleases could be technically in trouble there.

Re:pserver only

[Minna Kirai]

sites providing binaries of prereleases could be technically in trouble there

The safest way to avoid the trouble is to make it easily possible to get the source code alongside the binary. So just extend whatever scripts run the compile process to also build a tar.gz of the code used, and put it on the same webserver. If the users had the ability to get the source with the binary, your obligation is fulfilled.

If you don't do that, then you need to be able to fulfill requests in the form of "I want the source code for version 5.4.33 from 2004/3/6". If you have a CVS server, then it's pretty easy to respond to this (with a few caveats). If that CVS server is non-public, then developers will occasionally face the irritation of answering those source code requests manually, rather than just pointing to the available repository.

However, I have seen a real project get hurt because they didn't provide exact source code corresponding to their binaries. The damage in that case wasn't legal, it was technical- no users could submit correct bug reports or patches because they had no idea if what they were running had any similarity to the current code.

Re:pserver only

[Anonymous Coward]

Amen. They should be using an SSH wrapper, with a chroot cage. Of course, the OpenSSH authors have refused for almost the last 10 years to integrate the chroot capability directly into the package, but fortunately there's a vaguely reasonable chroot patch at chrootssh.sourceforge.net.

Unfortuantely, building the actual chroot cage is left as an exercise for the reader.

Hmm

[daserver]

Is this the third hole in cvs in a very short amount of time?

CVS and Subversion?

[Anonymous Coward]

I knew that Subversion was complete in its support for CVS users, but this is going too far.

Laugh, it's a joke.

Re:Unsurprising

[Eric Smith]

I really hope Linus will change his mind and will finally start using CVS or Subversion like the rest of the GNU and Free Software community does.

Better yet, if a free software source control system were to provide the features he needs, which are not currently available in CVS or Subversion.

Linux development is very decentralized, so Bitkeeper is much better suited to it than CVS or Subversion. The CVS and Subversion models are by their nature oriented toward having a single central repository, though there is a project to provide a wrapper for Subversion to support a decentralized model.

Reportedly arch has a model more like Bitkeeper, but I haven't tried it. I use CVS at work, and Subversion for my personal projects.

Re:Unsurprising

[The Bungi]

YHBT. Look at his nick and posting history.

I wonder

[sumdumass]

I wonder how many virus would be released that will take advantage of these security holes.

Is that a sign of how dificult the holes tend to be to exploint on *nix systems or is it more to microsoft being popular?

I don't doubt that a virus could take advantage of a security hole in *nix systems isn't the execution/spreading by default going to be alot harder?

Re:I wonder

[boots@work]

I wonder how many virus would be released that will take advantage of these security holes.

I think it's pretty unlikely there will be even one.

The number of machines in the world running public CVS servers must be pretty low: probably hundreds or thousands, but that's tiny compared to the number running Linux or Apache, let alone Windows. A worm that tried to propogate by scanning networks, as most do, would probably fizzle out. I don't think it would be worth the effort to write a virus.

Add to this the fact that CVS servers are probably a bit more diverse in OS/architecture than desktops, and that owners of CVS server probably pay a little more attention to them than does your average desktop user.

Anyone who wants to exploit this hole would be more likely to try to do it by hand against targetted important machines.

Any sane person running anoncvs should have it in a chroot jail, where an attack would cause less damage.

distro updates?

[Anonymous Coward]

just curious -- which distros have already released updates for these packages? i see debian released them promptly, but up2date on my redhat enterprise 3 does not yet show an update being available.

Re:distro updates?

[quantum bit]

Looks like FreeBSD's ports were updated about 5 and a half hours ago.

portupgrade -R subversion

CVS is part of the base system -- it was fixed in all the security branches early this morning.

Re:distro updates?

[MobyTurbo]

Slackware has released a security update.

Re:distro updates?

[Sweetshark]

gentoo: cvs and subversion
It is not mentioned on glsa up to now, however.

Heap overflow?

[Anonymous Coward]

Okay, I'm familiar with stack overflows. What is a heap overflow?

Re:Heap overflow?

[boots@work]

It's where a variable on the heap gets overwritten:

char *a = malloc(4), *b = malloc(4);
strcpy(a, "hello to all my fans in domestic surveillance");
/* kablooey */

The strcpy writes past the end of the allocated buffer. Several things might happen: first, and the best possible outcome is that it writes to an unmapped page and you die immediately with segv. Or it writes over a malloc control structure and a later call to malloc() or free() causes an indirect crash. (Sometimes called a "heap scribble".) Or it might write over some other heap variable, like b in this example.

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.

Re:Heap overflow?

[kasperd]

I'm familiar with stack overflows.

Maybe you are thinking about stack based buffer overflows. Stack based buffer overflows are often easy to exploit, and I think more than 50% of the worms on the internet use such exploits. It just means that you can overflow a buffer, which is allocated on the stack. When such an overflow happens, the return address is usually just a few bytes away, so you can change the return address to point into the buffer you just filled with code.

A stack overflow OTOH rarely happens, unless you trigger an infinite recursion in the code. Normally a stack overflow will just result in a DoS attack, because the OS will kill any process that overflows its stack. There should always be an unmapped page between the stack and any other mapping, such that overflows can be catched. (Could you overflow a kernel stack it would be an entirely different matter)

A heap overflow just means you overflow a buffer allocated from the heap. Any return address is far away, so they are not as trivial to exploit. But you can corrupt memory management data structures, which you might be able to use to have the memory management system return allocations overlapping with other important areas, which you might then be able to get overwritten. It can get very complicated. Take a look on Vudo - An object superstitiously believed to embody magical powers (Smashing The Heap For Fun And Profit)

Re:Wait!

[endx7]

Hasn't anyone LOOKED at the code?

Have you ever considered the possibility that they may have discovered the vulnerability by looking at the code?

They still have to make sure everyone knows about it, you know.

FC2

[Anonymous Coward]

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?

Re:FC2

[Anonymous Coward]

The CVS vulnerability, at least, is a heap-level vulnerability. While you should be able to protect the heap the same way you can protect the stack, I don't know if FC2 actually does so, or enables it by default (or maybe they put it in the advisory for those people disable it). Also, I heard this whole non-execute thing depends on the ELF file (so that things like JIT compilers can still work), and it doesn't work perfectly without a no execute bit. Heaps tend to be harder to exploit, because they don't grow down like stacks, but they can still be exploited with some cleverness (like this CVS exploit).

Anyway, I don't really know anything, just shooting the breeze here, but yeah, stack protection isn't a pancaea, although it really should help a lot. I'm with you, wondering about whether this is really going to allow arbitrary code execution.

I also can't believe Subversion had a flaw in the date parsing code. Anything that does parsing should always be checked and double checked for vulnerabilities, especially something as complicated as date formats (the Subversion date stuff is much more limited than CVS's, so you think they'd have gotten it right the first time). They certainly had enough time to work on it.

Re:FC2

[IamTheRealMike]

When exec-shield randomization is enabled, the DSO load addresses are scrambled. What that means is that while you can run arbitrary code, it's not really possible to make any library calls. Have you ever written non-trivial code without the presence of libc? I have, it's not much fun. You have to do everything using direct syscalls into the kernel, which is tricky and limited.

So in short while exec-shield in this case won't prevent the overflow (as it can with ASCII stack based overflows), it does make it harder to do things when you've infiltrated the system.

Re:Wait!

[The Spoonman]

all versions of CVS released before May 19th

This is the first time they looked at the code?

Re:Wait!

[endx7]

Of course not. This is not the first vulnerability either.

Just because you found a bunch of problems a while ago doesn't mean you shouldn't look at the code again later.

Re:Unsurprising

[boots@work]

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.

What Do I Do?

[ewhac]

I run a CVS server on behalf of a client on a FreeBSD box. It is running in pserver mode, and is launched by cvsd , which is a chroot() jail for CVS.

It is not clear from the sensationalistic news story what an administrator should do, or whether my particular configuration is vulnerable. Could a more knowledgeable person please summarize the issues involved, or point to the original vulnerability report so I can evaluate my risk?

Thanks,
Schwab

Re:What Do I Do?

[boots@work]

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.

Re:What Do I Do?

[endx7]

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.

Re:What Do I Do?

[JamieF]

And you will continue to hear about this vulnerability on Slashdot for several months, again and again, as though it's new information each time.

An argument for distributed version control

[boots@work]

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.

Re:An argument for distributed version control

[Anonymous Coward]

they require an active server that talks a complex protocol to an unauthenticated client

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 Coward

Re:An argument for distributed version control

[boots@work]

Hello Coward.

Yes, HTTP is a pretty complex protocol. However, you can write extremely simple read-only servers, such as thttpd or publicfile.

Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.

Distribution makes untrusted input problems worse since components of your 'server' can no longer even trust each other.

The version control system doesn't trust the web server, or receive any input from the network.

Thankyou for trolling!

Re:An argument for distributed version control

[Spruce Moose]

what, kind of like HTTP?

I think the point here is implementing another complex protocol is going to be a security risk. If you can use an existing framework for distributing files then you have already removed a source of security problems.

Re:An argument for distributed version control

[Anonymous Coward]

Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.

subversion uses apache, which means you don't have to have a whole new server. You have a point about being able to write simple read-only HTTP servers, but in order to run a version control system you're going to have to have writing somewhere, and distribution of the server isn't going to help.

As i pointed out before, it only makes more of the system untrustworthy. With the client/server model you can't trust input from the client, but with distribution you can't trust the client and you can't trust anything coming from the other servers.

The version control system doesn't trust the web server, or receive any input from the network.

Thankyou for trolling!

so you're going to have a non-networked distributed version control system! :o) Look who's trolling now.

the same Anon Coward

Re:An argument for distributed version control

[Anonymous Coward]

I think the point here is implementing another complex protocol is going to be a security risk. If you can use an existing framework for distributing files then you have already removed a source of security problems.

subversion uses WebDAV, an extension of HTTP, as a transport mechanism. It uses apache to handle HTTP/WebDAV requests. I don't think you can claim that they're reinventing the wheel.

the same Anon Coward

Re:An argument for distributed version control

[boots@work]

subversion uses apache, which means you don't have to have a whole new server.

Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days. Subversion deployed under Apache requires you to run a new DAV module under Apache -- and there has been quite a number of exploitable vulnerabilities in the neon DAV code over the last few years. Publishing a public Subversion repo requires you to run 10,000s of lines of new network-accessible code.

Also, Subversion requires that Apache have filesystem write access to the db files in the repo. So all in all it is a pretty unattractive proposition.

in order to run a version control system you're going to have to have writing somewhere

Writing in Darcs or Arch only occurs over SSH by the one person who owns the archive. There is no increased exposure. Anyone who is reading the anonymous archives can mail me diffs, as before. Now, perhaps they could try to break into my mailserver but they could try that before too.

I don't think your concerns about "more of the system being untrustworthy" reflect an understanding of the way these systems actually work. But if you want to give a proper argument please do.

Let me draw you a picture.

1: Project before using version control: one read-only web server, accessible over ssh, developer has an email account.

2A: After adopting darcs: no increase in exposure. Developer publishes stuff by pushing it onto the web server over SSH, just as they do for the web site. Developer gets patches by email.

2B: Contrariwise, after using CVS or Subversion, in the safest possible way to use them: A new service, of 10000s of lines of C code runs on the public server, accepting connections from arbitrary clients. The service needs to be able to write to files on the server. It is likely that the canonical repository resides on the same machine, so you put your crown jewels on the very machine which just opened up a new potential vulnerability.

To me, scenario 2B looks worse than 2A.

Re:An argument for distributed version control

[boots@work]

"Microsoft uses DCERPC, an extension of TCP/IP, as a transport mechanism."

I'm glad they used a standard protocol, though it's a shame it turned out to be a bit of a lame duck. But nevertheless, it is *another* protocol in the sense that nobody would be running it if it weren't for Svn. Therefore, it increases the amount of code that can be attacked.

I wouldn't be surprised if using svn under Apache doubled the amount of code reached by anonymous requests.

Note that now they've given up on getting everyone to install Apache2 and use DAV/SSL, the recommended protocol is svnserve, which was invented from scratch.

Re:An argument for distributed version control

[Anonymous Coward]

Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days

On one hand you're suggesting that people run thttpd and on the other you're complaining about switching to apache2?

Let me draw you a picture.

Subversion is capable of running over the local filesystem, just like arch. So you can use it that way for a single developer if you want. But the whole point of a networked version is that people who aren't on the same filesystem to share a code repository. If you had explored your own links you'd know that arch repositories can be accessed via a network as well.

Stop trying to claim that distributed operation is more secure because you'd be willing to use a distributed server in a different manner than you'd use subversion or cvs. They all do pretty much the same things, and have the same security downfalls. If you didn't want to run a network service you'd be more secure, but you can do that without 'distributed' versioning systems.

the same Anon Coward

Re:An argument for distributed version control

[Anonymous Coward]

"Microsoft uses DCERPC, an extension of TCP/IP, as a transport mechanism."

and this is relevant how?

it is *another* protocol in the sense that nobody would be running it if it weren't for Svn

WebDAV is an open standard that plenty of products support, including your precious arch. I'd hardly describe it as a lame duck.

Note that now they've given up on getting everyone to install Apache2 and use DAV/SSL, the recommended protocol is svnserve, which was invented from scratch.

do you have any idea what you're talking about, or do you just make things up as you go? they seem to still think that DAV is still an option. And how is it possibly bad that they give you the option of a standalone server (as well as tunelling via ssh, or filesystem access)?

the same Anon Coward

Re:An argument for distributed version control

[boots@work]

On one hand you're suggesting that people run thttpd and on the other you're complaining about switching to apache2?

I am pointing out that darcs/arch let you use whatever server you want. If you already have Apache, use Apache. If you have no preference and are worried about security, you might want to use something smaller than Apache. If you like SPARK Ada, use a server written in SPARK Ada. You have the choice.

Subversion, on the other hand, to publish over HTTP requires Apache2. And not only do you lose the choice, you also have to migrate to a server which is not yet widely adopted. Any reasonable sysadmin would be concerned by the security implications.

Subversion is capable of running over the local filesystem, just like arch.

Yes, but that's not helpful here. We are trying to publish our source so that anyone can download it. Subversion requires you to run a server: either anonsvn or anoncvs.

They all do pretty much the same things, and have the same security downfalls.

I consider needing to run an additional complex publicly accessible server to be a problem. This is a pretty basic principle of network security. It's not absolutely fatal, but it's pretty bad. Darcs and Arch do not require you to take this risk just to publish source.

Here's another security principle for you: "what's not there, can't break." We are posting on a story about remotely exploitable vulnerabilities in anonymous svn servers. That whole function is not required in Darcs/Arch and will therefore never have a security hole.

Stop trying to claim that distributed operation is more secure because you'd be willing to use a distributed server in a different manner than you'd use subversion or cvs. If you didn't want to run a network service you'd be more secure, but you can do that without 'distributed' versioning systems.

I'm not claiming either of those things. The scenario I describe allows a proper superset of what is possible with cvs/svn as they are used by open source projects.

Re:An argument for distributed version control

[boots@work]

I suggest you read the svn mailing list threads from a couple of years ago, when the developers realized that insisting on DAV was a major impediment to svn being adopted.

Also: why are you such a coward?

Re:An argument for distributed version control

[Anonymous Coward]

I suggest you read the svn mailing list threads from a couple of years ago, when the developers realized that insisting on DAV was a major impediment to svn being adopted.

*shrug*, well, it didn't stop my adoption. i followed the svn mailing lists for a while, until svn over ssh was developed. At that time svn over ssh was important to me (although subsequently got an apache setup). IMHO they have a pretty good selection of access methods, so you can choose one to suit your needs.

Also: why are you such a coward?

dedicated slashdot lurker: don't have an account, and not sure i want one. In fact, my reply to you was my first post ;o)

the same Anon Coward

Re:An argument for distributed version control

[jeremyp]

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.

Actually, you are not required to run anonymous access to either Subversion or CVS.

Anyway, allowing anonymous access to untrusted clients is a feature of FTP, SMTP, HTTP, SMB and many other protocols. It's always a weak point which must be programmed for. The logical extreme is not to allow any access whatsoever - then it might be secure.

Re:An argument for distributed version control

[boots@work]

Right, you are not required to permit anonymous access. You are not required to release your source at all. In fact, you are not required to develop software at all. Why don't you go and play outside?

But many open source projects want to do it. Making development source publicly available is a pretty important, though not absolutely necessary, condition for effective open development. (See Cathedral vs Bazaar, etc etc.) Closed projects have a completely different situation for source control security.

My point, which I would have thought has already been thrashed out sufficiently, is that Arch and Darcs allow you to publish source without requiring any anonymous access beyond a read-only web server.

(And before you say it: no project is required to have a web site, but how many don't?)

good thing only major users are safe...

[Frennzy]

Quote:

Apparently, major users of these products (Linux and BSD distros, Samba, etc.)

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.

Re:good thing only major users are safe...

[joe_bruin]

well, here were the options available to the discoverers of this bug:

1) tell a few trusted sources about this, let them patch and create patches for their users, and then reveal the exploit when they're ready.

2) tell everyone about the exploit (and patch) at the same time.

the difference is that in case 1, the users of red hat, debian, gentoo, freebsd, ... know that they can get a safe update from their vendor (who is already protected) asap. they don't have to wait for the vendor to verify whether their systems have been compromised before distributing the patch. both cases start a mad scramble for patches, but in case 2 the good guys are not a step ahead of the bad guys.

Re:good thing only major users are safe...

[pe1chl]

Apparently, major distributors (like SuSE) have also been informed, and now every user can download the update.

Dream On

[Anonymous Coward]

"non-biased view" on /.? What galaxy do you hail from? Do you get reruns of Green Acres on your home planet/habitat? Is Arnold Ziffel a God there?

Re: What unix really need

[lakeland]

Er, how is your proposal different from seteuid? A tiny setuid root wrapper gets authentication information, checks it with PAM, and then forks & seteuid to that user.

that's it all about

[golgafrincham]

i read this article. from the headline, one could have thought:

hehe, these stupid semi-smart "geeks", complaining all the time about these insecure microsoft products. and now? they got these nice security holes themselves!

but, you know what? i rtfa. and i read this particular line:

Apparently, major users of these products have been notified and have patched their systems.

i mean, is that cool or what? the message that the system is insecure arrives at the same time as the patch. and you dont't have to be a major user (translated: msce) to get the patch.

this is just one reason i trust my sources to cvs.

Neither of the bugs were bounds-checking related..

[Ayanami Rei]

Re:Build errors

[Minna Kirai]

Any ideas?

The obvious suggestion, of course, is to get it pre-compiled from Fink. They apparently are on an older 1.11 version, but I'd imagine they'll try to backport security fixes quickly... maybe.

The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs :pserver on the internet. Instead run cvs :ext over ssh. That won't necessarily stop authorized users from escalating their privs (although for this exploit it does), but should totally protect you from "cold calling" attacks.

As for those specific error messages- I don't have a Mac with me here, but I've noticed before that the OS X setup of standard libraries is different from what BSD (and Linux and other Unix) normally use. They don't have the same library files much source code assumes it can find, so the Apple-provided compiler makes some secret substitutions to allow software to build. But that's guesswork, and it can sometimes guess wrong, producing inscrutable situations until you sit down with "nm" and "ld" to work out exactly what's happening. (Probably more trouble than it's worth)

Re:Build errors

[pauljlucas]

The 2nd obvious suggestions is to point out that even regardless of this particular vulnerability, you should never run cvs :pserver on the internet

I don't. Why did you think I did?

Instead run cvs :ext over ssh.

I do.

one more thing

[boots@work]

It is possible that there's a vulnerability in the patch command, or in the equivalent in darcs or arch that accepts changes from contributors. Such a vulnerability might allow a malicious submitter to take over a developer's machine when they try to read or apply the change.

This is conceptually no different to a vulnerability in a mail client or HTML viewer or any other program that views files read over the network. Those things happen, but they're not generally seen as such a big problem as an attack on a network server, for two reasons: the attack is harder to carry out, and easier to trace.

I'm only likely to even think about applying a changeset from a credible source, whereas anoncvs by definition accepts requests from any IP. If they do attempt an attack then I have a record of where it was sent from, etc.

One fix is that change requests should be easy for a human to read without a special tool. Darcs does this, and Arch and Bitkeeper do not. It's probably pretty unlikely there could be an exploit that would look harmless when viewed by a human. In this case basically the only way Darcs is going to be invoked is when the input has already been vetted by a person.

Source Compatibility vs. Binary Compatibility

[Lennie]

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.

Sourceforge were involved in testing the patches.

[dr_labrat]

11 May 2004 Sourceforge discovered that the patch breaks compatibility with some pserver protocol violating versions of WinCVS/TortoiseCVS

Pudgy??

[kahei]

Subversion is not pudgy! It's just... buxom! And anyway, it's in much better shape than that flabby Aegis thing. So there.

references to cvs security problem

[tinkerton]

The issue affects cvs +pserver. It's listed with references at Mitre.

Correction.

[Anonymous Coward]

The interior nodes are also contributors, so the tree can actually contain 2^0 + 2^1 + 2^2 + ... + 2^7 = 2^8 - 1 = 255 contributors with 7 levels. Still nowhere near millions, but the "tree" used in e.g. the Linux kernel has much higher fanout than 2 (at least near/at the top), so you end up with many more nodes.

Small point.

[warrax_666]

When people here speak of a "database" they really mean a "database system".

Technically, you're correct, though. But I would content that the definition of "database" is so wide as to make it completely worthless to refer to a "database" and not "database system" in any technical context -- which is why people use "database" as shorthand for referring to a database system.

Re:Build errors

[Sweetshark]

I don't. Why did you think I did?
Because the bug affects only the pserver.

As usual

[psergiu]

Quoting from the OpenBSD Erata Page this problem was remedied from May 5, 2004

I've posted some CVS RPMs...

[tcopeland]

...up on CougaarForge.

Just the source and the i386 binary RPMs, but perhaps they'll be useful to someone...

FALSE! You little history revisionist you.

[Anonymous Coward]

You just made a double-fault.

... was originally a Perl program ...

Patently False

HISTORY of CVS:

[...]

CVS algorithms actually started in Universities several decades ago and CVS implementation started out as a bunch of shell scripts written by Dick Grune, who posted it to the newsgroup comp.sources.unix in the volume 6 release of December, 1986. While no actual code from these shell scripts is present in the current version of CVS much of the CVS conflict resolution algorithms come from them. In April, 1989, Brian Berliner designed and coded CVS. Jeff Polk later helped Brian with the design of the CVS module and vendor branch support.

[...]

source: CVS-RCS-HOWTO

Ironically, CVS was originally a Perl program until a C version was needed to make it real software.

It's NOT! It's something else. irony misuse

Sure They Want a Name Change

[4of12]

SCO wants their name changed to Sourceforgery.

That won't do much good because SCO will too easily become confused with alternative labels such as SoreForce or SoreFarce.

SCO will love this

[Anonymous Coward]

Place your bets: How long will it take for Darl McBride to issue a press statement saying that this flaw proves that IBM have been able to covertly insert SCO Unix code into the Linux kernel?

OT:Sig...

[mdielmann]

How many programmers does it take to change a LED?
None. It's a hardware problem.

How many engineers does it take to change a LED?
5. One to find the manual, and 4 to try to follow the instructions.

How many people does it take to change a LED?
One, but he has to remember how. After all, it was so long ago...

Commercial software is as bad or worse

[spitzak]

I have worked on commercial software for three different commercial companies, including a very large one (three letters, starts with S), and also on a "smaller" open-source project (fltk).

Even this small open source project gets me far more "code review" than anything at any commercial place. Nobody looks at commercial code, they do not have the time. EVERY single fix and improvement is suggested, located, and coded by me. All I get are bug reports, almost all of those are "I ran it for 3 hours, I forget what I did, and it crashed!"

In fltk, certainly there are bugs reported, and just like the commercial stuff the same bug is reported dozens of times, by people too lazy to even check if the bug is already in the database. But I also get many patches where people actually found out about the bugs. The number of patches I have received for the commercial software (where many of the users have access to the source code)? ZERO!

The other comment about accepting blocks of unknown code is bogus. The submitted patches are all about 1 line long and I can easily tell if they really fix the problem. Same is true for the commercial software, incidentally. Any contributed code is always read over and analyzed.

I can catagorically state that my OSS software is higher quality than my commercial software. Now I spend about 10x or more time on the commercial software, and it is probably 20-30x more complicated than the OSS stuff. Therefore it is more valuable, but that does not mean it is better.

Unfortunately the real difference I am talking about is the difference between commercial development and a hobby. Unfortunately for your argument, it is obvious to me that "hobby" software is much higher quality than commercial. The difference is in the motivation of the authors, and the fact that they know their work is visible to the world.

Gentoo bug report for this vulnerability in cvs

[Corporate Gadfly]

Here is the gentoo bug report for this vulnerability.

Its already in portage and marked stable.

emerge sync
emerge cvs

should get you going.

Re:Gentoo bug report for this vulnerability in cvs

[Corporate Gadfly]

And the gentoo bug report for subversion. subversion 1.0.3 has the fix and is in portage (marked stable on x86). subversion 1.0.4 is the newer version and is not yet in portage.

Re:Unsurprising

[Anonymous Coward]

Very interesting moderation... Someone posts a comment and get moderated as Score:-1, Troll (50% Troll, 50% Offtopic) because some joker said he's a troll directing to his posting history as a proof (which I checked out and saw only one post moderated down, a Score:0, Redundant post) and then some guy says that in fact the original "Score:-1, Troll" has a point, for which he gets moderated as Score:4, Interesting (50% Interesting, 50% Insightful) while the original post is still -1, Troll... Meta-moderation, here I come!

Moderation abuse?

[Anonymous Coward]

How exactly is parent troll and off topic? In my opinion it's way Underrated. I'm not the only one. For example, boots@work (17305) also thinks that parent has a point. It's obviously not off topic and parent is not a troll (check out his posting history). It might be flamebait, but is IMHO also very Insightful.

I appreciate the candor of your post...

[zogger]

.. and of the other thoughtful replies on the thread. This goes to help prove a point I've tried to make several times, but being a non coder I am at a loss how to present it without sounding overly churlish. The point is, software is usually presented with no warranty. The argument is, that it can't be done. I have always thought it could be done, that very good code could be released, but it wasn't, for the various reasons outlined in this thread, all of which CAN be addressed, but for the most part, are not.

I guess my point is, as a company/developer/project takes on quality and auditing as job 1,rather than just rush it out the door when it's "good enough", their market star will shine, because they have so little *true* competition then.

I hope it happens.