Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Software

Security Holes in CVS and Subversion Found 250

Posted by simoniker 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.
This discussion has been archived. No new comments can be posted.

Security Holes in CVS and Subversion Found More

Security Holes in CVS and Subversion Found

Comments Filter:

  • Sourceforge... (Score:5, Interesting)

    by Samah ( 729132 ) on Wednesday May 19, 2004 @07:08PM (#9200402)
    ...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*
  • Man- I used CVS in a project just last year. Sure hope Olivetree has patched their server.

  • Thankfully, I use Visual Source Safe (Score:5, Funny)

    by Anonymous Coward on Wednesday May 19, 2004 @07:09PM (#9200413)
    If you compromise it, it's so broken you can't even use it to control source.
  • No amount of code review, open source or proprietary, can guarantee that there isn't some lurking bug in the application. We have probably not yet found all the ways there can be security holes, much less all the actual holes in any given thing.

    Developers and admins have to keep security aware constantly, which is one of the hardest problems in real production environments.

    • Re:Just goes to show... (Score:5, Insightful)

      by The Bungi ( 221687 ) <thebungi@gmail.com> on Wednesday May 19, 2004 @07:41PM (#9200604) Homepage
      I'll post something along these lines in the next Microsoft vulnerability article and we'll see if I get modded +5 with alacrity.


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

        Don't you do this already? If not, you're behind the curve. MS Fanboys are quick to post this and quick to mod it up.

        It's a pitty it misses the point (not that there aren't Linux fanboys missing the point too).

    • Re:Just goes to show... (Score:5, Insightful)

      by bladernr ( 683269 ) on Wednesday May 19, 2004 @08:08PM (#9200735)
      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?

      • Re:Just goes to show... (Score:5, Insightful)

        by bluGill ( 862 ) on Wednesday May 19, 2004 @08:35PM (#9200875)

        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.

      • Re:Just goes to show... (Score:5, Insightful)

        by Zancarius ( 414244 ) on Wednesday May 19, 2004 @08:39PM (#9200897) Homepage Journal
        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!
      • I actually did a small report on OSS a little while back; I'm about to fix it up for my good copy. Needless to say it's terribly written, and mostly based upon my own knowledge. However, I did come across a few of the problems you're describing.

        You're right that the main problem with the "millions of reviewers" argument is that there is some question as to whether this review even happens; I personally hate reviewing my code. OSS, as it is, is either developed as a commercial product, and thus security

      • Re:Just goes to show... (Score:2, Interesting)

        by Anonymous Coward
        Yes we are lazy and many of us want to have our name in the contributers list. That is the biggest reason for contributing to the code.
        Debugging code is the quickest and easiest way into the contributers list.

        Also when a project enters "frease" it's the ONLY way to get on the contributers list.

        Having said that. The only real way to make sure the code is bug free is to make it really small.

        The less code you have to manage the easier it is to see the bugs.

        But you'll never make a powerful operating system

      • Re:Just goes to show... (Score:4, Insightful)

        by darnok ( 650458 ) on Wednesday May 19, 2004 @09:55PM (#9201265)
        I think you raise a really good point - hope you don't get modded down and people miss it...

        I think a sizeable number of people read through source code as a way of educating themselves. OSS code is (as you point out, rightly or wrongly) seen as a source of very well-written code, and if I was going to teach myself something from someone else's source code, I'd be inclined to use OSS code as a starting point.

        As these people educating themselves start to learn about what e.g. a buffer overflow is, what it looks like and how to avoid it, they'll think back to the OSS code they've read through and either mentally congratulate the author or possibly notify him/her to say their code has a security hole in it. I'm not sure: OSS code may even be used as a teaching tool in universities, in which case there will be lots of reviewers.

        This reviewing-as-you're-learning approach would probably only apply to big OSS projects such as Apache or the Linux kernel I can't imagine a lot of people are suddenly going to start teaching themselves about buffer overflows using e.g. the Ethereal source. However, it's projects such as Apache and Linux that would be most at risk from buffer overflows; a buffer overflow in Ethereal, while it may be important, isn't likely to lead to lots of exploits in the real world.

        Good point though - I'll be interested in what other replies you get

      • 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 have two software products, very small, that I've put out into the wild. I licensed them under BSD, so it's open source. My program PHPortfolio [outshine.com] had a weakness in version 1.0. It only worked if installed at the top

      • I've been wondering if it isn't possible that its even less secure.

        Of course not! There are thousands of slashdot posts asserting that it's not true. If that doesn't constitute proof, I don't know what does.

  • Second Level security? (Score:4, Interesting)

    by Manip ( 656104 ) on Wednesday May 19, 2004 @07:10PM (#9200422)
    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.

    • Re:Second Level security? (Score:5, Interesting)

      by CajunArson ( 465943 ) on Wednesday May 19, 2004 @07:14PM (#9200452) Journal
      I think SELinux [nsa.gov] 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.

    • Re:Second Level security? (Score:5, Informative)

      by Delirium 21 ( 336429 ) on Wednesday May 19, 2004 @07:24PM (#9200502)

      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.
      • Since the program itself has been hijacked, it bypasses exactly the sort of second-level protection you suggest.

        But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.

        (Much more important, of course, is that CVS- or any important server- be run behind a separate, simpler server handling authentication. Usually ssh)

        However, much research has shown that sandboxes themselves can be vulnera


        • But CVS and Subversion have no need to write to a "system" file, so this protection can work fine. And indeed, every serious CVS server admin has done something like this.

          Of course, anything that CVS or Subversion is able to write to would be data a patient attacker would like to modify.
        • Additionally, why does CVS or SVN need access to WRITE to the files at all? At least the anonymous portion. For non-anonymous access, the problem goes down to how Unix programs operate. Two choices can be made: 1) the program suids to the user requesting access 2) the program does the action on behalf of the user, weither he has a local account or not.

          2 should never happen. It is insecure by design.

          1 is preferable. Access happens as those needing access, system level. 1 however, for traditional Unix, requ
      • Security is a hard problem

        P class or NP class?

    • Re:Second Level security? (Score:4, Insightful)

      by jonastullus ( 530101 ) on Wednesday May 19, 2004 @07:24PM (#9200506) Homepage
      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 ;-)

      • Re:Second Level security? (Score:5, Insightful)

        by Minna Kirai ( 624281 ) on Wednesday May 19, 2004 @08:34PM (#9200866)
        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)
    • The most obvious reason for subversion repos is that subversion uses a small number of berkeley db files for the entire repository, so filesystem level controls may apply to the entire repository, but not individual files.

      With cvs, this is possible if the filesystem uses acl's. If not, there are only the standard user, group and other categories, so there are only 3 possible access levels. Additionally, when a new file is created, the admin will have to set the permissions on these.

      I believe it would be

  • Great! (Score:5, Funny)

    by Psychor ( 603391 ) on Wednesday May 19, 2004 @07:12PM (#9200436) Homepage
    Great, I'll grab it just as soon as the source for the patch goes into CVS! Oh wait...

  • open source databases?? (Score:4, Insightful)

    by Anonymous Coward on Wednesday May 19, 2004 @07:13PM (#9200443)

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

    • CVS and its pudgy cousin Subversion are not databases.

      CVS uses RCS as a back-end store. Subversion uses Berkley DB as a back-end store.

      • Re:open source databases?? (Score:5, Insightful)

        by damiam ( 409504 ) on Wednesday May 19, 2004 @07:44PM (#9200615)
        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.
      • CVS uses RCS as a back-end store.

        Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active. But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".
        • Hasn't been true for a long time. Now CVS reads/writes directly, with no RCS process active.

          Sorry, meant to say RCS format plain text files.

          But even if that were still the case, saying "CVS is a database" is like "airplanes are wings".

          Database [reference.com]

          I do not agree with you. Just like I wouldn't agree if you said filesystems weren't databases. For crying out load, my blog is a database!
    • "CVS repository."

      repository
      1. See data dictionary.
      2. The core of a CASE tool, typically a DBMS where all development documents are stored.

      Shit, seems like calling it a '..source database' isn't too far off the mark for a news outlet. Better than 'the fabric of the internet' or something gay.

      give these guys a break.
      • that should have read:

        repository
        1. /database/ See data dictionary.
        2. /programming/ The core of a CASE tool, typically a DBMS where all development documents are stored.
    • They may use the *concept* of a database *internally*, but then again so do iTunes and Emacs and probably a bunch of other programs.

      I concur about emacs. Not only it is a database but it can also do this and that. Now if only I could make my emacs to brew coffee.
    • Which leads me to wonder -- is there a freelance PR business, specialising in open source software and available to work from afar (effectively contract tele-commuting), serving the OSS market?

      Someone/group that would volunteer or work on a nominal per-hour fee to get well-worded and accessible info out to the masses?

      If there isn't, it sounds like there might be an opportunity out there for groups smaller than someone like RedHat, IBM, Sun, etc...

  • "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

  • uh oh! (Score:2, Funny)

    by L0stm4n ( 322418 )
    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 )

  • Another security flaw found (Score:5, Funny)

    by Canberra Bob ( 763479 ) on Wednesday May 19, 2004 @07:28PM (#9200533) Journal
    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.

  • pserver only (Score:5, Insightful)

    by cperciva ( 102828 ) on Wednesday May 19, 2004 @07:36PM (#9200580) Homepage
    Note that this problem only exists in pserver code. Anyone using pserver on critical systems needs to reassess their security anyway.

    • Re:pserver only (Score:3, Insightful)

      by arkanes ( 521690 )
      You mean like sourceforge? Anonymous CVS access is a pretty import thing to alot of projects.

      • Re:pserver only (Score:3, Interesting)

        by cperciva ( 102828 )
        You mean like sourceforge?

        I'm quite happy with saying that SourceForge should reassess their security.

        Anonymous CVS access is a pretty import thing to alot of projects.

        There are much better options; CVSup and rsyncing tarballs are probably the best.

        • Re:pserver only (Score:3, Insightful)

          by kryptkpr ( 180196 )
          I'm quite happy with saying that SourceForge should reassess their security.

          Do you actually run projects at SourceForge? You have to use a ssh tunnel to be able to write to any project repository.
  • Is this the third hole in cvs in a very short amount of time?

  • CVS and Subversion? (Score:5, Funny)

    by Anonymous Coward on Wednesday May 19, 2004 @07:40PM (#9200597)
    I knew that Subversion was complete in its support for CVS users, but this is going too far.

    Laugh, it's a joke.

  • FC2 (Score:4, Interesting)

    by Anonymous Coward on Wednesday May 19, 2004 @08:36PM (#9200879)
    According to the alerts below, Fedora Core 2 has these vulnerabilities, and furthermore, they can lead to arbitrary code execution:

    FC2 CVS alert [lwn.net]

    FC2 Subversion alert [lwn.net]

    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?

  • What Do I Do? (Score:3, Interesting)

    by ewhac ( 5844 ) on Wednesday May 19, 2004 @09:18PM (#9201078) Homepage Journal

    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 [tudelft.nl], 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

  • An argument for distributed version control (Score:4, Informative)

    by boots@work ( 17305 ) on Wednesday May 19, 2004 @09:21PM (#9201094)
    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 [abridgegame.org] and Arch [gnuarch.org] 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.

  • good thing only major users are safe... (Score:4, Informative)

    by Frennzy ( 730093 ) on Wednesday May 19, 2004 @10:13PM (#9201334) Homepage
    Quote:

    Apparently, major users of these products (Linux and BSD distros, Samba, etc.)


    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.

Slashdot Top Deals

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Close