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.

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

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

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

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

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

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

  10. 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
  11. 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.
  12. 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