Slashdot Mirror
Security Holes in CVS and Subversion Found
joe_bruin writes "News.com.com is reporting a two separate vulnerabilities that affect current versions of CVS and Subversion source control systems. Apparently, major users of these products (Linux and BSD distros, Samba, etc.) have been notified and have patched their systems." Update: 05/20 02:01 GMT by S : Clarification that there are separate issues for both CVS and Subversion.
...had better get proactive :)
/. to help out its fellow OSDN member*
God knows it took them ages to get their CVS server problems resolved a few years back.
*points
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
Man- I used CVS in a project just last year. Sure hope Olivetree has patched their server.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
If you compromise it, it's so broken you can't even use it to control source.
Developers and admins have to keep security aware constantly, which is one of the hardest problems in real production environments.
Why don't highly important OSS projects use second level protection, like only allowing X user to modify files N Y P at a file system level? If such measures where taken the worst that could happen is a DOS attack.
This also helps to sell managed code for mission critical systems.
Great, I'll grab it just as soon as the source for the patch goes into CVS! Oh wait...
Flaws drill holes in open-source databases
Geez, this is why open source needs a frickin' PR department. These flaws DRILL HOLES!!! Into Open source DATABASES!! OMGLOLWTF??!111
CVS and its pudgy cousin Subversion are not databases. They may use the *concept* of a database *internally*, but then again so do iTunes and Emacs and probably a bunch of other programs.
Does CNET not understand the concept of a version control system? Hint: only people who know what they are use them in the first place.
Regardless, I only use these things via SSH, and have never recommended running CVS with pserver or Subversion via Apache or its server, except on a well-firewalled LAN. I think that's the common practice anyway.
Pretty good rule of thumb: if you can run the service over an SSH tunnel, DO IT! Don't assume Yet Another Server Daemon is secure. Then you just have to keep an eye out for SSH exploits (which you should be doing anyway since SSH bugs are more serious than bugs in TEH OPEN-SORCE DATABASS anyway!).
Of course not. We're all looking to see if we need to update or patch something.
::jafomatic
"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
Creative Demolition
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 )
superman runs linux
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!
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.
I'm confused. I thought SVN was a rewrite of CVS...? Is the flaw based on a common library or something? Puzzled.
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? ... to voice their own propaganda and TCO-FUD?
wouldn't this soon become an institution for companies like IBM, Novell, HP, SuSE, RedHat,
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!
Note that this problem only exists in pserver code. Anyone using pserver on critical systems needs to reassess their security anyway.
Tarsnap: Online backups for the truly paranoid
Is this the third hole in cvs in a very short amount of time?
Am I the only one who sees a bit of a contradiction here?
Laugh, it's a joke.
how about: java is not Free
...). of course, this does not make it any better and in my opinion manual memory allocation is the GREATEST possible waste of a programmer's time (sensible exceptions excluded ;-).
while all these buffer overflows, etc are more than a nuissance in C/C++, many of the bugs stem from a misunderstanding on the part of the programmer (i.e. use of deprecated functions,
languages featuring garbage collection, length encoded strings, array bound checks, etc are hopefully the future, but at the moment (not least due to the lack of a free java compiler/interpreter/RE) many libraries and toolkits are still written for C/C++ and thus are also mostly used from these two languages.
ESR used to do this, but it looks like he is looking for a replacement
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.
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.
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
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!
There is a reason no one has ever built a statue to a committee.
Sarcasm and hyperbole are the final refuges for weak minds
YHBT. Look at his nick and posting history.
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?
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.
Nothing great was ever achieved without enthusiasm
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.
I'd rather be lucky than good.
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.
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?
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.
-- The world is watching America, and America is watching TV.
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.
I think a JIT compiler written in ocaml would be cool. I hear ocaml is an excellent language for writing compilers.
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.
Dr Hos'e may have indulged in the trollish arts in the past, but he does have a point:
how many otherwise great programmers and source control systems gurus cannot post bugfixes to CVS and Subversion codebases thanks to Bitkeeper's EULA
I've received patches from kernel developers for my open source programs. The BK licence makes them give up the right to file CVS or Subversion bug reports, in order to use BK for free.
I don't think CVS or Subversion would suit Linus's style, but maybe Arch or Darcs will in the future.
Which one happens depends on the libc and the allocation pattern, but for any app on any particular system it may be predictable.
The one that is easiest to exploit is writing over another variable, like b. This gives the attack a way to write into a variable they weren't meant to access, which leads in short order to the computer being stretched wide open.
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
Editor, A1-AAA AmeriCaptions
These vulnerabilities are a consequence of an architectural security flaw in both CVS and Subversion: they require an active server that talks a complex protocol to an unauthenticated client.
Whenever you allow an untrusted client to control code running on your server, there is a risk of a compromise.
The distributed version control systems Darcs and Arch show a better way. Read-only access requires only some read-only files published over HTTP. Since most projects already have a web site, this means there is no increase in the network services that need to be offered.
Once those files are downloaded, the anonymous user can get updates, make their own patches, branch -- all the facilities allowed by anonsvn/anoncvs and more.
I 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.
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.
Homonyms are fun!
You're driving your car, but they're riding their bikes there.
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.
The ratio of people to cake is too big
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.
JikesRVM is written in Java.
Yes, but it's a research VM. That's a horse of an entirely different color.
Slackware has released a security update.
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.
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.
beer as in "free beer"
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Any ideas?
: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.
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
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)
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
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.
Not sure, but I think one issue is, in the Win32 world things need to be binary comp. where as in the OSS world, source comp. is enough.
If you have a vuln. in a Debian package, you do
apt-get update && apt-get -u install package
You'll see that (especially if it's a library) all kinds of other packages will automatically be upgraded
The same will not happen in the Win32-world.
New things are always on the horizon
11 May 2004 Sourceforge discovered that the patch breaks compatibility with some pserver protocol violating versions of WinCVS/TortoiseCVS
The secret of success is honesty and fair dealing. If you can fake those, you've got it made. (Marx)
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).
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)
Do you care about the security of your wireless mouse?
Subversion is not pudgy! It's just... buxom! And anyway, it's in much better shape than that flabby Aegis thing. So there.
Whence? Hence. Whither? Thither.
ah like my ass? that too has a high overhead on startup, but once it gets going the shit comes out full throttle!
This comment does not represent the views or opinions of the user.
The issue affects cvs +pserver. It's listed with references at Mitre.
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.
HAND.
I don't. Why did you think I did?
Because the bug affects only the pserver.
Quoting from the OpenBSD Erata Page this problem was remedied from May 5, 2004
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
gentoo: cvs and subversion
It is not mentioned on glsa up to now, however.
...up on CougaarForge.
Just the source and the i386 binary RPMs, but perhaps they'll be useful to someone...
The Army reading list
You just made a double-fault.
Patently False
source: CVS-RCS-HOWTO
It's NOT! It's something else. irony misuseAt 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.
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.
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.
"Provided by the management for your protection."
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...
Sure I'm paranoid, but am I paranoid enough?
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.
Its already in portage and marked stable.should get you going.
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
.. 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.
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.