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."
This kind of thing always seems to happen after I burn a new release of something.
Sigh...
Life is the leading cause of death in America.
Sounds like a good way to alter the code stored on a hacked machine to install backdoors for you to get into others.
Do you OSS folks actually read through every line of source before you build something big like Apache or Squid or SAMBA, just to make sure noone has altered the code?
I don't need no instructions to know how to rock!!!!
So if CVS is in CVS, maybe somebody rooted CVS's CVS to apply a patch to backdoor CVS, even with new CVS patches to CVS? ;)
cant you guys read? It is an additional patch!
The patch from e-matters does NOT fix the double free bug!!!!
ah yes, another representation of sofware's circle of life.
exploit, patch, exploit, patch, exploit, patch.
insert elton john music here
Karma: Raspberry Kiwi
Yea, I used CVS to update my mplayer so I could watch some newer Windows Media files sent to be by some nice young woman at "Brintey_XXX_Hot_NAKED_ J-LO_CAUGHT_ACTION@hotmail.com". Shortly thereafter, I came back from the bathroom to discover that my desktop image was replaced by a big penis with the KDE gears for testicles, and I couldn't start any programs.
What fool runs their cvs pserver as root? Every installation I've ever seen has it running as a non-privelidged user. While of course any remote compromise is not good, lets not exagerate the severity of this problem.
Using your sig line to advertise for friends is lame.
I wonder how you operate to remove those?
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
I think it's time to give up on C for most Internet application development, and use languages which eliminate this wide class of bugs. Banning C altogether is of course an overstatement, but C code in an application should be treated like setuid code. There should be as little of it as possible (the occasional optimized inner loop of something, for example), and it needs to be scrutinized very carefully before deployment.
Anyone know what language Subversion is written in?
I'd say part of sensible planning is trying to lower the effect of accidents (or bugs), even if you can't prevent all of them. That means wearing the seat belts in your car, and using array checking and garbage collection in your programs.
This is why I only offer access to benign users.
The point is software is about tradeoffs. Take Windows 95, for example. Any time something becomes corrupted, you get a Blue Screen. If MS wanted to prevent the bug from spreading and corrupting anything else, they'd reboot immediately. But people are willing to take the risk of running with a potentially unstable system because there are advantages: the risk of further bugs is small, I'd like to save the document I've been working on the past three hours, or it's just not worth my time to wait through a reboot.
Choosing C is about tradeoffs too. Coding in C means you get a fast language that produces a well-understood output. And you are also very sure that no language vendor is ever going to change the underlying behavior and break your code. Plus, the C source can be compiled and run on practically every OS out there with minimal overhead.
The person who writes the software gets to decide where the software sits on this tradeoff. If you disagree, you are free to write your own server in whatever language you want.
A witty [sig] proves nothing. --Voltaire
I became a GCC maintainer for precisely this reason.
And I'll just say to you, pclminion, that those JPGs in your home directory aren't as, ahem, secure as you'd like to think.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.)
Yeah, and we need to quickly find a way to blame Microsoft for this CVS bug. Any ideas?
MSDOS: 20+ years without remote hole in the default install
Holy screaming fuckmonkeys, Batman. You have no idea how much work we/they go through to ensure that GCC is buildable by anything even resembling a C compiler. (I say "we/they" because I generally don't have to worry about it in my little corner of the world.)
GCC was intended from its earliest days to replace whatever native (proprietary) compiler came with or was sold for your native (proprietary, evil, etc) Unix platform. When you build GCC, it actually is built three times:
Copy #3 is then used to build the rest of the compiler (other languages) and the runtime libraries. Copy #3 is what gets installed on your system.
Huge chunks of the GCC source are still maintained in K&R C for those platforms which don't have an ISO (ANSI) C compiler. Chunks of the standard C library have homegrown replacements inside GCC, for those platforms which aren't ANSI/POSIX.
Fortunately, the number of those systems has dwindled, but at one time they were the majority.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
> The SSH exploits could exist regardless of what language.
This is totally wrong. How can you claim this?? Safe languages would NOT have been vulnerable to the integer overflow attacks. The only recent ssh flaw (AFAIK) that was language-neutral was the one where the passwd file was being improperly interpreted on some platforms. The rest would not have been exploitable if sshd were written in Java, SML, O'Caml, or another safe language, period.
My response to the rest of your post can be summed up as: C behaving as it is designed is no consolation if the design is bad, and the design is bad as far as security is concerned. It's true that it's possible (to a certain extent) to grin and bear it, but why would you want to do that??
Someone asked what I'd recommend instead of C. I don't know. I don't think there's a One True Language. Lately I'm coding in Python and like it, though it has its own shortcomings. Java is C-like enough to be comfortable for today's C and C++ programmers. I like the Java language but despise the runtime systems that are usually shipped with it. Perl seems like a monstrosity to me (awk with cancer) but with the -T option (taint checking), it, too, saves you from making a lot of bugs that are easy to miss when writing a C program.
If you've ever written setuid code (at least responsibly), you know the feeling of paranoia and vigilance you have to bring to every line of it that you write. I'm very skeptical if you tell me you bring the same paranoia to all the code you write. Of course there's no magic bullet to secure programming, but there are tools available (i.e. languages with fewer exposed sharp edges) that provide various kinds of safety nets that can rescue you a sizeable percentage of the time. It's foolish not to use those tools.
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.
> The point is, it will always, always, without exception, rely upon the developer not fucking up.
> If you remove the capacity for pointers, they'll find some other way to exploit the system. There is no such thing as
> security.
This is a pretty extreme position to take, and I think it's impractical. Using more safe languages can make our programs more reliable and more secure, by limiting the ways that programmers can make exploitable bugs. Of course, a language that doesn't allow the developer to make any holes at all, even if he's trying, is not very useful (in a sense ssh itself is a 'hole' that grants access to someone who 'exploits' it with a password). I am not claiming that we should program in these languages, if in fact they exist. But there is a rich middle ground between such a useless language and a language like C that makes it so easy and dangerous to make mistakes. These languages absolutely do make a very popular class of errors (that occur even among the world's best programmers) vanish instantly, and that to me is obviously a step in the right direction.