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."
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
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.)