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.
I think "Malicious" is the more... conventional choice.
-=Best Viewed Using [INLINE]=-
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.
When you look at all the expolits in commercial software and then compare them to the amount found in free software you will see what I mean. I used to be a big Microsoft fan until I looked at all the money I save with free Gnu/BSD/linux software and now I never look back.
All the best,
--Achmed
Swaribabu Consulting Inc. -- We code so you don't have to
I wonder how you operate to remove those?
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
I thought this affected Windows also......
D.A.K.D.A.E.---- Deny all Knowledge, Destroy All Evidence
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.
It's not as bad as that; most local exploits will only give you the same privileges that you already have, not elevate them. For example, the mutt hole made it possible for certain data items to run code as the same user that is running mutt. There are very few programs that are allowed to run with superuser privileges, and those packages should be kept to an absolute minimum. CVS, Apache, samba, ftpd and their like should NEVER run with root privileges; at worst a daemon may need permission to open a privileged port, but then relinquish such privleges. At best, they run in a chroot'd environment (like any FTP server that accepts incomming requests...).
The wheel is turning, but the hamster is dead.
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)
Bashing goto is so tired. It's a great construct for a procedural language. As someone above pointed out, most languages (even the LISP I championed earlier) are written in C. Well, C is "written" in assembly, and all assembly has is goto. Not to mention the performance advantages goto can offer over more structured control flow (for evidence, grep -r goto /usr/src/linux ).
Maybe goto is counter to the spirit of object-orientation, but then again "OO" and "Procedural" are orthogonal when you get right down to it: C++ is OO and procedural and Haskell can be OO but is not procedural.
Goto is not the enemy!
All's true that is mistrusted
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.)
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
Seriously, that's a stupid attitude to have. When you're talking about security, you have to assume the worst from the start. That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
> Again, the problem is not the language, it's the coder. ... Don't blame a language for operating exactly as it's designed to.
p ache
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:
Quake I, II, and III
Linux Kernel, OpenBSD Kernel, FreeBSD Kernel
SSH
perl
Half-Life
X11
BIND
dhcpd
a
mozilla, internet explorer, netscape navigator, konqueror, opera
etc.
etc.
etc.
etc.
(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!!)
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!)
Many "functional" languages (like SML and O'Caml) have imperative features for exactly this reason, just as C has (sort of) the ability to pass around functions. It's true that Haskell (purely functional) is not a great language to write I/O intensive software in (though Haskell has its own ways to do IO, and Haskell fans have written many I/O intensive, interactive applications, including network daemons). However, Haskell would be far from the worst language, because at least you'd have a better chance of ending up with a program that works correctly (doesn't provide remote root access to anyone).
I maintain that SML and O'Caml ("functional" languages) are utterly practical (and in fact superior to C and C++ in terms of correctness and ease of use) for network software. I've written a full-featured ftp server in SML to replace my buggy wu_ftpd, so I have some evidence to back this up.
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)
Well I guess that makes all VB coders geniuses then, since they never get buffer overflows. They must just be the greatest bunch of programmers around.
It's just hard to kill people when you are driving a go-cart in a predefined track.
That means assuming coders will make mistakes, no matter how good they are. Even the best coders do make mistakes. In a language designed to be secure, the impact of coding mistakes is minimized.
C was never designed to be secure. Blame C programmers for insecure code, not the language. There are plenty of steps you can take to ensure safe C code. If you expect a secure application, and you use C, than take the proper steps to make it secure. It's user error.
It's not a stupid attitude, it's a philosophical attitude. I'm not defending C, but it works exactly as designed. End of story.
Dacels Jewelers can't be trusted.
There is enough blame for everyone. When a C programmer makes a mistake, he deserves some of the blame. But if the language is inherently insecure, it is also partly the fault of the language. The way you're talking, we should just all use C for our secure code and punish programmers when they make mistakes because it's their fault. Instead you can realize that part of the fault is with the language and replace the language. Even though C wasn't designed to be secure you can still blame it for security related problems.
In the end, the semantics of the word "blame" aren't important. The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
But if the language is inherently insecure, it is also partly the fault of the language.
Ok, the language isn't insecure... well, you can make it secure, and have setuid wrappers on all your scripts and have a truly secure implementation. It would constrict freedom. The language allows people to write insecure code. All the recent SSH notifications on CERT were implementation, and not C-specific problems.
The important thing is that people realize that C programmers make security mistakes because C is an insecure language, and don't use C in security-critical areas, or review security-related C code extremely thoroughly before release.
C programmers make mistakes because they get lazy and don't properly audit their code. After every function you write, simply give it another good look and make sure it cleans up after itself, and maintains proper design. It's perfectly fine then. Like I said in another comment, I've worked on a project that had a bit over 600K lines. You could have done the same in about 250K or so, but it was 600K because everything was modularized. Taking design queues from Knuth, it was extremely robust and very stable. No memory leaks, no buffer overflow problems. Everything that got alloc'd actually had a comment where the variable would get free'd at.
It's called good design of software, not good design of language.
Dacels Jewelers can't be trusted.
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.
Java isn't any less "free" than C even though it is a much more secure language. It is just as turing-complete as C is. If you use a language with security features built in you spend less time auditing and more time being productive. As we all know, programmer time is more expensive than CPU time, so a little less efficiency is excusable. Even so, the technology behind new languages is maturing to the point where it's hard to tell the difference anymore.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
If you are using Debian, you should add security.debian.org to your package source list. As usual with most problems like this, a patched version has already been released. Take a look at http://www.debian.org/security/ for more info on how to set your system up to take advantage of security patches.
I'm aware of your ftp server. I'm also aware that it is the only one of its kind. Why don't you write some more software and compete to determine which is better.
How we know is more important than what we know.
It's also a concrete fact that there are only 6 of those polluting the Internet, so let's not go into comparisons.
[btw, your crapflooding is getting tiresome, especially when it's so stupid]
And it seems to me, your stack got hacked
By a buffer overflow.
You're never fixed by patches,
'Cause you still free() twice.
And I would try not to install you,
If I had another choice.
cvs diff you now,
And hope they don't get r00t.
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.
Just create a source tarball for each release and store it offsite. Then you can at any time check out the old sources from CVS and compare them with your tarball. Then you can compare the source tarball of this release with the one from the last one, ideally read that diff manually for bugs, and make a cvs diff, which you compare with the diff of the tarballs you made.
You can do that at any interval you choose.
Um, so, if CVS runs as user "cvs", which can write your source. Have fun to verify that nobody installed an exploit in your software
Yes, running as user prevents from the CVS binary itself being comprimised, which would allow same nasty tricks to hide exploits. But maybe you can achieve almost the same with smart, unusual rcs files.
But otherwise, your source is probably the most valueable asset on that machine (you're not running the company database on the same machine, are you?), so write access to the source *is* severe.
A "normal" build like the one you describe doesn't even do the compile twice. Only step #1 is done. (That's not what we call a normal build, so that's why I didn't mention it.)
You call the triple-stage idea "actually paranoidly," but I assure you that it's still needed when the native compiler/library is buggy or in some ways lacking. Most Linux users and distros use an earlier version of GCC as the "native compiler" in step #1, which makes steps 2 and 3 (usually) unnecessary. Perhaps that's why you think 2 and 3 are paranoid, but it's good to remember that GCC's target platform is far wider than Linux.
The fact that a simple "make"/"make all" does not do the 3-stage build performed by "make bootstrap" is considered a bug by some of the maintainers. We're actually trying, in the medium- and long-term, to have more of the compiler built in the 3-stage fashion, not less.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
The Fox project at CMU is studying the use of advanced programming languages, such as ML, for the construction of system software. They already have a web server written in ML.
Java isn't any less "free" than C even though it is a much more secure language.
Garbage collection is not secure. Safe pointers is not secure. Java is not secure. C is not secure. A language can be as insecure as the coder tells it to be. Nothing you want to believe will change this.
If you use a language with security features built in you spend less time auditing and more time being productive.
If you worked with me, you would be fired right now. This is the exact mentality that leads to security problems in the first place. "The language is secure so I don't need to audit"
No offense, but you really just destroyed your credibility with me by saying this, and I'm done talking to you.
Dacels Jewelers can't be trusted.
"The language is secure so I don't need to audit"
Who said that? Did I say that? No, I did not say that. I said you spend less time auditing. Please don't put words in my mouth. Since there are (for example) no double free errors in Java, you don't have to check for them. Therefore you spend less time auditing. You still have to audit for errors that still can occur in Java. Duh.
I'm done talking to you.
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
Classic "uh-oh, I'm losing the argument" cop-out. Oh well.
No, it's the "I'm arguing with an idiot with no scope of reality" statement. I didn't say you said that verbatim, but what you did say was just as idiotic. You shouldn't spend less time auditing. You should not sacrifice security if the application should be secure (always). Any developer of mine that decides he doesn't need to audit, or spend less time than what should be applied, will find himself quickly unemployed.
Since there are (for example) no double free errors in Java, you don't have to check for them.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second. Auditing code ensures good design, not syntactic checking. Good design will eliminate most of those problems.
It seems you don't know C well enough to know that at a quick glance you should be able to see any of the conventional mishap-bugs (double free, buffer overflows) relatively easy.
Dacels Jewelers can't be trusted.
But you're not sacrificing security. If you spend less time auditing code that has much fewer security holes, you get the same level of security in the end. You can never guarantee perfect security, only extremely good security. If the language gives you a head start, it takes less time to achieve the same level of security.
Pairing alloc/free's in properly designed code takes all of about a tenth of a second.
Oh, right. And next you'll tell me that loop constructs are for lazy programmers because constructing them with gotos only takes "about a tenth of a second". Give me a break. For one thing, it takes longer than that in any reasonably complex project. For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
For another thing, humans will occasionally make a mistake. Poof, security hole. Compilers don't make those kind of mistakes. Why not let the compiler do it, both for coding speed and security reasons?
Which is why most security-based applications (aside from openSSH, which I wont get into) don't have many problems aside from implementation logic issues. If you design and code with security in mind, it's a moot point.
Dacels Jewelers can't be trusted.