Slashdot Mirror
Security Holes in CVS and Subversion Found
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.
Man- I used CVS in a project just last year. Sure hope Olivetree has patched their server.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
"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
Creative Demolition
From the FAQ:
""First Post" comments are one of those odd little memetic hiccups that come out of nowhere and run amok. Basically, people with altogether far too much spare time sit and reload Slashdot, hoping that they will get the "First Post" in a discussion. This is one of those things that the moderation system was designed to clean up, and for the most part, it works. "First Post" comments usually get moderated down as off-topic almost instantly."
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.
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.
hell..even C#
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.
that should have read:
/database/ See data dictionary. /programming/ The core of a CASE tool, typically a DBMS where all development documents are stored.
repository
1.
2.
I.O.U One Sig.
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".
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.
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 and Arch 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.
Demonstrably false.
Just update CVS from FreeBSD whenever they apply the fix. If FreeBSD haven't made a new release yet, then you might want to turn off public access until it's fixed.
The issue has been announced via the normal announcement channels for FreeBSD and an advisory which explains what to is available. I actually got the FreeBSD advisory before I heard about it on slashdot.
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.
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 had a weakness in version 1.0. It only worked if installed at the top-level of a Web server. The first few people who installed my software coded up patches for themselves, and sent bug reports to me. In a later version, the thumbnailing feature was poorly done, and someone "donated" a few lines of code to improve it. So yes, the "eyeballs" argument seems to work even for small projects. Although they didn't give me their patches in every case (which is OK by the BSD license), they did give me bug reports.
I also have a program called phpBB Blog which, if you look in my forums, has a 1.0 beta out. A handful of people have downloaded it, but I've had no bug reports & no patches so far. In this case, it looks like the extra eyeballs (and there are a few) are not doing me much good. Or else the code is solid, which I doubt. :)
In any case, I think the open source model does work on a small level for small projects and it works on a big level for big projects. I suspect the only place it would fall apart is trying to tackle a big project with only a small base of support/fans. Having only a very few eyeballs scanning over a huge codebase doesn't sound like it can ensure high quality in the majority of such cases. That might need some cathedral-style development.
My Greasemonkey scripts for Digg &
That's right. In November 2003, there was an unsuccessful Trojan-CVS attack on the Linux kernel.
Linux kernel development process thwarts subversion attempt
The attack failed because, basically, the CVS repositories for the linux kernel are not the real source trees -- they are just mirrors of people's bitkeeper trees.
And here is a Trojan FTP attack. Of course CVS and FTP are different protocols, but the idea is similar -- inject malware into the OSS development stream.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I'm familiar with stack overflows.
Maybe you are thinking about stack based buffer overflows. Stack based buffer overflows are often easy to exploit, and I think more than 50% of the worms on the internet use such exploits. It just means that you can overflow a buffer, which is allocated on the stack. When such an overflow happens, the return address is usually just a few bytes away, so you can change the return address to point into the buffer you just filled with code.
A stack overflow OTOH rarely happens, unless you trigger an infinite recursion in the code. Normally a stack overflow will just result in a DoS attack, because the OS will kill any process that overflows its stack. There should always be an unmapped page between the stack and any other mapping, such that overflows can be catched. (Could you overflow a kernel stack it would be an entirely different matter)
A heap overflow just means you overflow a buffer allocated from the heap. Any return address is far away, so they are not as trivial to exploit. But you can corrupt memory management data structures, which you might be able to use to have the memory management system return allocations overlapping with other important areas, which you might then be able to get overwritten. It can get very complicated. Take a look on Vudo - An object superstitiously believed to embody magical powers (Smashing The Heap For Fun And Profit)
Do you care about the security of your wireless mouse?
So in short while exec-shield in this case won't prevent the overflow (as it can with ASCII stack based overflows), it does make it harder to do things when you've infiltrated the system.
You just made a double-fault.
Patently False
source: CVS-RCS-HOWTO
It's NOT! It's something else. irony misuse