Slashdot Mirror
Remote Root Exploit in CVS
RenHoek writes "Security expert Stefan Esser from E-matters discovered a bug in CVS version 1.11.4 and lower, that can give malignant users remote root access. The exploit was confirmed on BSD, but other OS's like Linux, Solaris and Windows are vulnerable too. A security advisory can be found here and there is also a patch available. CVS version 1.11.5 which is fixed can be downloaded as well."
cant you guys read? It is an additional patch!
The patch from e-matters does NOT fix the double free bug!!!!
You're making a joke, but the problem you mention is actually a serious one. Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.
Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.
From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
A very interesting read.
What fool runs their cvs pserver as root?
Ummm... People using Debian?
On a stock Woody box:
grep cvs /etc/inetd.conf /usr/sbin/tcpd /usr/sbin/cvs-pserver
cvspserver stream tcp nowait.400 root
Well, D comes to mind. So does Eiffel. And, now that gcj exists, Java. These are't real desireable languages, but they solve the buffer overflow/pointer freeing problem.
... interesting.)
The thing is, as long as C code requires type casts, it will be fragile. Java casts know the size of the thing that they are casting, but C doesn't. Eiffel doesn't allow you to cast. I'm not sure just what D does, but it says that it handles this, too. I don't think that this could even be handled by a redesign of C. It's too embedded in the language. C is, essentially, a portable assembler, and intentionally doesn't check anything it doesn't have to. Really helps to optimise memory use. But the pointers just aren't safe, and I don't think that they can be made safe. (I'm not saying that some particular chunk of C code isn't safe. Most is. But there's not much possibility of an automatic check, and even a manual check can be
Earlier someone suggested using Scheme code... well, Scheme handles this problem, but it introduces it's own (or at least the early versions of Lisp did). And the coding model is too different.
So D is probably the best choice. But, unfortunately, the first version isn't yet into Beta. Whoops! (D is closely modeled on C, but was willing to break compatibility to fix design problems, where C++ required keeping compatibility. And D was designed a lot later. So D has built-in garbage collection, and eliminates the need for pointers, etc.)
Another good feature of D is that it can call C code directly. gcj should be able to also, but I haven't figured out from the docs just how to do it. (Anyway I like the syntax and feel of D more than I do that of Java.)
Then for higer level applications there are things like pyrex. Another beta compiler. Pyrex is designed to sit in between Python and C, so that you can code small pieces in C for efficiency, and the larger pieces in Python for speed in development and understandability.
Programmers can be much smarter than any garbage collections system in small chunks of code, as well as more efficient, as long as they are careful and don't make any mistakes.
I think we've pushed this "anyone can grow up to be president" thing too far.
This post is severely uninformed, like most others that defend C for network applications. Here's why.
...) does."
) . For well optimized code, that number can easily be within 20%. Of course, writing in a high level language gives you more time to work on better algorithms, which as any good programmer knows, is what *really* matters in its performance.
o m7misc/net/mlftpd/). It took me only about a weekend and the result was about 10% the length of the C program. It also saturates my 100mbit link without using more than a few percent of my crappy 400mhz CPU. (It transfers data using basically the same mechanisms that C uses, so C doesn't have any advantage in that part.) Most importantly, I sleep tighter at night knowing that my server is 100% buffer overflow, double-free, and integer overflow free.
- "Java would probably crash with some sort of exception instead of happily running in an invalid state... but do you really
want anyone to remotely crash the server daemon either?"
No, of course not, but that's about ten million times better than giving the attacker remote root access. Script kiddies don't get much out of crashing servers, but they do out of compromising a computer. And it is much much harder to detect and clean up afterwards.
- "C is absolutely, bar none, the fastest language for slinging raw bytes around (err... ignoring assembly, but it's close) -
and that's pretty much what a CVS server (or FTP, or HTTP, or
Wrong. Most server programs are network and disk-bound, *not* CPU bound. (In fact, I believe that CVS spends most of its CPU time doing diffs, that is, text processing--something that C is notoriously awful at.) Most users wouldn't notice if their CVS server used 20 times more CPU. C is no more than 2x faster than modern safe languages like O'Caml and SML (http://www.bagley.org/~doug/shootout/craps.shtml
I'm not just bullshitting, either: Last summer after another wu_ftpd remote hole I rewrote the damn thing in SML (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/t
- "... the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug."
Unfortunately, C encourages such bad program design, and then makes bugs deadly. How else can you explain so many buffer overflows, double-frees, and integer overflows? Don't tell me it's the programmers, because almost all of the most revered C software, written by the most talented programmers I know, has had such bugs. (Quake III, ssh, linux kernel, wu_ftpd, apache, perl, etc., etc., etc.)
That's so that setuid() can be called later once user has logged in, so it's not running as root all the time. Pretty standard implementation for most servers that require logging in.
I've set my anonymous CVS pserver so that it's running under anoncvs uid which has no write access to any of the files in CVS. Only problem with this was that CVS wants to create lock files, but it could be done by setting +t flag for all directories so they will behave like /tmp. That pretty much prevents this exploit from causing me any harm. That and grsec.