Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Holes in CVS and Subversion Found

Posted by simoniker on from the nee-naw dept.

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.

32 of 250 comments (clear)

  1. Sourceforge... by Samah · · Score: 5, Interesting

    ...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*

    --
    Homonyms are fun!
    You're driving your car, but they're riding their bikes there.
    1. Re:Sourceforge... by nacturation · · Score: 5, Funny

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

      --
      Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
    2. Re:Sourceforge... by jpetts · · Score: 5, Funny

      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

      --
      Call me old fashioned, but I like a dump to be as memorable as it is devastating - Bender
    3. Re:Sourceforge... by Bingo+Foo · · Score: 4, Funny

      SCO wants their name changed to Sourceforgery.

      --
      taken! (by Davidleeroth) Thanks Bingo Foo!
    4. Re:Sourceforge... by PotPieMan · · Score: 5, Interesting

      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.

    5. Re:Sourceforge... by Geekenstein · · Score: 4, Funny

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

    6. Re:Sourceforge... by Chainsaw · · Score: 4, Insightful

      Actually, you can make a separate tree for the lock files. Not that hard, just check out the administrative CVSROOT directory and examine the config file (if I remember correctly). It's there in someone of the files.

      --
      War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
  2. Thankfully, I use Visual Source Safe by Anonymous Coward · · Score: 5, Funny

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

  3. Second Level security? by Manip · · Score: 4, Interesting

    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.

    1. Re:Second Level security? by CajunArson · · Score: 4, Interesting

      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.

      --
      AntiFA: An abbreviation for Anti First Amendment.
    2. Re:Second Level security? by Delirium+21 · · Score: 5, Informative

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

      Friends come and go, but enemies accumulate.
    3. Re:Second Level security? by jonastullus · · Score: 4, Insightful

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

    4. Re:Second Level security? by Minna+Kirai · · Score: 4, Insightful

      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)

    5. Re:Second Level security? by Minna+Kirai · · Score: 4, Insightful

      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.

  4. Great! by Psychor · · Score: 5, Funny

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

    1. Re:Great! by bladernr · · Score: 4, Funny

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

      --
      Sarcasm and hyperbole are the final refuges for weak minds
  5. open source databases?? by Anonymous Coward · · Score: 4, Insightful

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

    1. Re:open source databases?? by damiam · · Score: 4, Insightful

      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.

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
  6. Re:Just goes to show... by cduffy · · Score: 4, Insightful

    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.

  7. Another security flaw found by Canberra+Bob · · Score: 5, Funny

    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.

    1. Re:Another security flaw found by thebatlab · · Score: 4, Insightful

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

  8. Re:uh oh! by GregAndreou · · Score: 4, Funny

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

    --
    My freedom ends where someone else's begins
  9. pserver only by cperciva · · Score: 5, Insightful

    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
  10. CVS and Subversion? by Anonymous Coward · · Score: 5, Funny
    I knew that Subversion was complete in its support for CVS users, but this is going too far.

    Laugh, it's a joke.

  11. Re:Just goes to show... by The+Bungi · · Score: 5, Insightful

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

  12. Re:Is it the same flaw? by breser · · Score: 4, Informative
    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.

  13. Re:Just goes to show... by bladernr · · Score: 4, Insightful
    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?

    --
    Sarcasm and hyperbole are the final refuges for weak minds
  14. Re:Just goes to show... by bluGill · · Score: 5, Insightful

    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.

  15. FC2 by Anonymous Coward · · Score: 4, Interesting

    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?

  16. Re:Just goes to show... by Zancarius · · Score: 5, Insightful

    In a commercial environment, I make developers do it, but, except on the few big OSSes that are run basically like commerical operations, how are we really sure it is more, and not less, secure?

    While you may be correct -- Open Source may very well be riddled with just as many bugs -- the argument shouldn't be focused on which is more secure but rather on which is more fixable. Open Source is rendered a benefit that closed source lacks: the ability to fix the source yourself. Compare the security flaws released in the last six months on sites like CERT--generally, Open Source outfits release patches much sooner than commercial counterparts. Sure, this doesn't always hold true, but Open Source grants yet another benefit: Users of Open Source are, IMO, more aware of the implications and importance of security and are thus more proactive when an exploit is discovered.

    And, again, I can't stress the "fix it yourself" argument enough!

    --
    He who has no .plan has small finger. ~ Confucius on UNIX
  17. Re:Heap overflow? by boots@work · · Score: 5, Informative
    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.
  18. FALSE! You little history revisionist you. by Anonymous Coward · · Score: 5, Informative

    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