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.

7 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 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. Re:Sourceforge... by Bill+Currie · · Score: 3, Interesting

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

      --

      Bill - aka taniwha
      --
      Leave others their otherness. -- Aratak

  2. 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.
  3. 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?

  4. Re:Unsurprising by boots@work · · Score: 3, Interesting

    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.