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.

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