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.

Comments

Re:Second Level security?

[Delirium 21]

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.

Re:Is it the same flaw?

[breser]

No whoever submitted the article to Slashdot was confused. If you read the news.com article carefully it is clear that they're separate issues.

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.

Re:Heap overflow?

[boots@work]

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.

An argument for distributed version control

[boots@work]

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.

Re:open source databases??

[Dahan]

You can't provide anonymous cvs ... access through ssh.

Demonstrably false.

Re:What Do I Do?

[endx7]

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.

good thing only major users are safe...

[Frennzy]

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.

FALSE! You little history revisionist you.

[Anonymous Coward]

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