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
"Do I trust that person", instead of, "Do I trust that person and every bloody person who just might be able to alter a file in the long chain of responsibility from him compiling it to me installing it."
Actually... it's more like:
"Do I trust that person and every bloody other person in the 'bazaar' that has access to add/modify the code before I compile it and install it."
vs.
"Do I trust that person and every bloody person who just might be able to alter a file in the long chain of responsibility from him compiling it to me installing it."
Volunary peer review is just that... everyone assuming that some other peers are reviewing the code means that it most likely doesn't get done unless you do it yourself. md5 checksums just mean that you downloaded the stuff that was on the site and it matches the md5 number that was generated when it was put out (could already have had bad stuff in it). In the end, unless you examine the code yourself, you are engaging in the same amount of trust either way.
Good thinking, but there is no problem.
The CVS repository on cvshome.org was updated on January 15th, well before the exploit was published.
(but wow, wouldn't that have been cool? every rushes to update their copy of CVS, and now you've got your backdoor installed everywhere? hoo ya!)
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.
Since you can't cause a buffer overrun/overflow in something like Java or .NET, maybe that's a good choice to write stuff in.
Or maybe not - someone will find a way to exploit those and anything alse that catches on.
I think you are missing an important point. There is a big difference between exploitation and honest mistakes. The CVS bug is just that -- an unintentional bug. The (debatable, but I agree with) advantage of languages such as Java and C# is that make it much harder for us mere mortals to accidentally introduce system-level bugs into our code. I ran FAR FAR away from C/C++ when Java became a reasonable alternative, because I saw countless incidents of crash bugs caused by mismatched malloc/free or new/delete.
Now, I'm certainly not recommending that anyone go and write an OS kernel in Java. While it would likely be a 'safer' kernel for a particular group of common bugs, it would also likely be dog slow. But, I'm amazed at what people pull off with VM-based languages everyday, so, who knows? I remember the sick guy back in college 12 years ago who seriously considered writting an OS in ML (ML the langauge, not machine language) because it would be so safe and easier to prove correct.
Back on topic, I think we'd be hard-pressed to find a CVS server that is taking such enormous load that it couldn't be implemented in Java or C# and perform perfectly well. Look at what people have done with resin -- a J2EE app server written in Java -- as reported on /.
Mind you, I'm not volunteering for the port -- won't pay the bills and all that -- but I wish I had the time to do it.
Yes, it's true. This man has no dick.
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.
I blame the language. The reason is this: C makes it so easy, and so dangerous, to make such bugs, that they are extremely common, even among the best programmers. I challenge you to explain why some of the most revered software created by some of the most revered C hackers has had buffer overflows, if it's not the language's fault:
The language operates exactly as it is designed. It is human error. Not language error. Just because a gun makes it easy to kill people, doesn't mean guns kill people.
Things like the operating system kernels are not so easy to rewrite in a modern safe language, but network daemons are an *obvious choice* and are also the most dangerous!!
It really is not so hard to never use an unbounded function (snprintf instead of sprintf) or to count malloc() and frees() and if you do your code well structured, than it works. If you test your code with code that will cause buffer overflows everywhere, you will find them. If you do your math correctly, you will find them. If you don't, it's human error.
By the way, C garbage collection is crappy compared to built in support in a modern language: It needs to be conservative, and can't compact the heap. (Of course, that doesn't stop the authors of gcc from using it!)
Anything external will usually be less reliable and robust than something built-in to the language specifications. But, I would trust the authors of gcc more than you, no offense mate.
Dacels Jewelers can't be trusted.
I think you must have never written any big software, because it's not as simple as you think.
Sorry, but buffer overflows are that simple.
Look at the complexity of the recent SSH bugs, for instance. Human error is universal, even if you are trying hard, and even if you are an excellent programmer (see the list in my previous post). And it is extremely dangerous. Regardless of whether this is C's "fault" (can a tool really be at "fault"?) or the programmer's "fault" for choosing a tool that is so dangerous, it is clear to me that C is a bad language for writing security-critical software.
Again, C operates exactly as designed. The SSH exploits could exist regardless of what language. Saying the reason why there are security exploits is because software is written in C is exactly like saying car crashes occur because people drive sports cars.
I think you missed my point: The authors of *gcc*, which is THE quintessential C program (in a strong sense), have found it so difficult to manage memory manually that they've resorted to using a garbage collector, despite its deficiencies. If anything is a testament to the inappropriateness of C, that is.
Did I ever say it wasn't a pain in the ass? No. I said it operates exactly as it is designed, and nothing more. There is nothing else aside from that. I'm an advocate for best-tool-for-the-job, if that requires C than it's the best tool.
Accusing a language which functions according of spec of being dead and the cause of security concerns is stupid. Yes, C is harder to write secure applications in. No, it doesn't mean it should die. Yes, you must be very vigilant while writing C.
As for GCC, the C based garbage collection is not bad when used properly. It is not as full featured as Java, but it still works. I'll still code in C++ for most of the projects I work on because it is a good trade-off for power/security.
The faults of everything you list are the faults of people. I've worked on 600K lines of software written in C. It was all very self-contained, and didn't have any buffer overflow style problems. Why was it so big? Because it was designed with security in mind, and was very verbose and robust in what it did. If you audit every function thoroughly, garbage collection becomes useless.
I was working on this piece of network code that was written in C, I had an off-by-one error that was really screwing everything up. My code was very tight, and had another set of eyes look at it and was easily able to spot my mistake.
Well written code, regardless of language, will do exactly what you tell it to do, regardless of the complexity of how you tell it to do it.
Dacels Jewelers can't be trusted.
Sorry but "normal" builds of gcc like configure-make-make install only perform step 1 and 2. To perform step 3 as well you have to call a special make target for this actually paranoidly step, but do not remember of hand which.
--
Karma 50, and all I got was this lousy T-Shirt.