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.

21 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.
    2. Re:Second Level security? by Minna+Kirai · · Score: 2, Interesting

      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 vulnerable, incomplete (think race conditions), and so on.

      I don't really believe that- if the sanbox boundaries are sufficiently simple, verification is managable- but it's irrelevant anyway.

      A CVS server will normally only have write permission to the files making up the source code repository. A correct sandbox would give no more protection than simple file ownership (which still allows exploits if a buffer overflow occurs- if a user could insert malicious code into the source without producing the normal check-in message, she can do much mischief to all the other developers)

    3. Re:Second Level security? by wasabii · · Score: 2, Interesting

      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, requires the process to have root access to suid. This is unacceptable. Windows NT programs do not need Administrator access to conduct operations on behalf of a user, they just need that user's crediantials, which are passed to a trusted subsystem, and that subsystem grants the system the permissions neccassary. The OS doensn't trust the software. (I am in no way saying that Windows is "more secure", im just saying that in this particular example, it has the potential to be more secure, cleaner, and easier.)

      What Unix really needs is a new way to suid. I would say it would work like this: The program passes the username/password the user sent to another component, which is out of process. Such as a daemon, or maybe kernel level. That other process uses the local system configuration to make a determination weither or not the CVS daemon should be able to conduct operations on the user's behalf, and grants only those permissions needed to a certain context, even involving a time frame if neccassary. The program does the actions, and then "releases" the access.

      That's how It Should Be.

  3. Backdoors in our projects by Anonymous Coward · · Score: 1, Interesting

    Hmm, so does this mean that we need to go looking for backdoors in every piece of code out there that uses a publicly visible CVS tree? Better get started!

  4. Is it the same flaw? by Anonymous Coward · · Score: 1, Interesting

    I'm confused. I thought SVN was a rewrite of CVS...? Is the flaw based on a common library or something? Puzzled.

  5. Re:If CVS was implemented in Java... by fishdan · · Score: 2, Interesting
    Your post actually raises some interesting issues, but you will almost certainly be modded as flamebait because of your silly petty comments about older languages. There really are no bad languages, only bad developers. Except for Scheme -- it sucks (kidding!!)

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

    1. Re:FC2 by Anonymous Coward · · Score: 2, Interesting

      The CVS vulnerability, at least, is a heap-level vulnerability. While you should be able to protect the heap the same way you can protect the stack, I don't know if FC2 actually does so, or enables it by default (or maybe they put it in the advisory for those people disable it). Also, I heard this whole non-execute thing depends on the ELF file (so that things like JIT compilers can still work), and it doesn't work perfectly without a no execute bit. Heaps tend to be harder to exploit, because they don't grow down like stacks, but they can still be exploited with some cleverness (like this CVS exploit).

      Anyway, I don't really know anything, just shooting the breeze here, but yeah, stack protection isn't a pancaea, although it really should help a lot. I'm with you, wondering about whether this is really going to allow arbitrary code execution.

      I also can't believe Subversion had a flaw in the date parsing code. Anything that does parsing should always be checked and double checked for vulnerabilities, especially something as complicated as date formats (the Subversion date stuff is much more limited than CVS's, so you think they'd have gotten it right the first time). They certainly had enough time to work on it.

  7. Re:Just goes to show... by clandestine_nova · · Score: 2, Interesting

    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 is essential, or it is developed small-scale, where security is a very miniscule issue in comparison.

    Logically, it makes sense that the more popular a piece of software is, the more it gets used and the source browsed. As well, the bugs that do get found can be fixed much faster than their commercial counterparts.

    Although I've yet to see whether that argument is really true, it sounds logical to me.

    --
    Discworld.
  8. Re:Just goes to show... by Anonymous Coward · · Score: 2, Interesting

    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 in 10 lines or less.

  9. Re:Wait! by endx7 · · Score: 2, Interesting

    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.

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

  11. What Do I Do? by ewhac · · Score: 2, Interesting

    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
  12. Re:pserver only by cperciva · · Score: 2, Interesting

    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.

    --
    Tarsnap: Online backups for the truly paranoid
  13. Re:open source databases?? by bruthasj · · Score: 2, Interesting

    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

    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!

  14. Re:An argument for distributed version control by Anonymous Coward · · Score: 2, Interesting

    Almost all projects that publish anoncvs also publish web pages, and putting additional files on the web site is much less risky than running a whole new server.

    subversion uses apache, which means you don't have to have a whole new server. You have a point about being able to write simple read-only HTTP servers, but in order to run a version control system you're going to have to have writing somewhere, and distribution of the server isn't going to help.

    As i pointed out before, it only makes more of the system untrustworthy. With the client/server model you can't trust input from the client, but with distribution you can't trust the client and you can't trust anything coming from the other servers.

    The version control system doesn't trust the web server, or receive any input from the network.

    Thankyou for trolling!

    so you're going to have a non-networked distributed version control system! :o) Look who's trolling now.

    the same Anon Coward
  15. Re:An argument for distributed version control by boots@work · · Score: 2, Interesting

    subversion uses apache, which means you don't have to have a whole new server.

    Subversion uses Apache2, which *is* a whole new server from what the majority of people are running these days. Subversion deployed under Apache requires you to run a new DAV module under Apache -- and there has been quite a number of exploitable vulnerabilities in the neon DAV code over the last few years. Publishing a public Subversion repo requires you to run 10,000s of lines of new network-accessible code.

    Also, Subversion requires that Apache have filesystem write access to the db files in the repo. So all in all it is a pretty unattractive proposition.

    in order to run a version control system you're going to have to have writing somewhere

    Writing in Darcs or Arch only occurs over SSH by the one person who owns the archive. There is no increased exposure. Anyone who is reading the anonymous archives can mail me diffs, as before. Now, perhaps they could try to break into my mailserver but they could try that before too.

    I don't think your concerns about "more of the system being untrustworthy" reflect an understanding of the way these systems actually work. But if you want to give a proper argument please do.

    Let me draw you a picture.

    1: Project before using version control: one read-only web server, accessible over ssh, developer has an email account.

    2A: After adopting darcs: no increase in exposure. Developer publishes stuff by pushing it onto the web server over SSH, just as they do for the web site. Developer gets patches by email.

    2B: Contrariwise, after using CVS or Subversion, in the safest possible way to use them: A new service, of 10000s of lines of C code runs on the public server, accepting connections from arbitrary clients. The service needs to be able to write to files on the server. It is likely that the canonical repository resides on the same machine, so you put your crown jewels on the very machine which just opened up a new potential vulnerability.

    To me, scenario 2B looks worse than 2A.