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!).
"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
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.
Note that this problem only exists in pserver code. Anyone using pserver on critical systems needs to reassess their security anyway.
Tarsnap: Online backups for the truly paranoid
Laugh, it's a joke.
how about: java is not Free
...). of course, this does not make it any better and in my opinion manual memory allocation is the GREATEST possible waste of a programmer's time (sensible exceptions excluded ;-).
while all these buffer overflows, etc are more than a nuissance in C/C++, many of the bugs stem from a misunderstanding on the part of the programmer (i.e. use of deprecated functions,
languages featuring garbage collection, length encoded strings, array bound checks, etc are hopefully the future, but at the moment (not least due to the lack of a free java compiler/interpreter/RE) many libraries and toolkits are still written for C/C++ and thus are also mostly used from these two languages.
But just to make things clearer here are the links to the advisories:
Subversion
CVS
I also put up a more clear description of the Subversion problem up on subversion site.
java is not slow, it has a high overhead on startup!
it is just that the loading of the runtime engine, garbage collector, on-the-fly-compiling by the interpreter, etc produce a high overhead at startup. thus small, short programs seem to run slow, whereas in big applications the speed penalty is marginal!
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
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?
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.
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.
Slackware has released a security update.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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
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?
You just made a double-fault.
Patently False
source: CVS-RCS-HOWTO
It's NOT! It's something else. irony misuse