Remote Root Exploit in CVS 293
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."
Murphy's Law (Score:3, Funny)
Sigh...
CVS, huh? (Score:3, Insightful)
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?
Re:CVS, huh? (Score:5, Insightful)
No. But I do check the md5 checksums that I get from at least 2 or 3 different sources. Especially with server software like Apache, Squid or SAMBA.
Do you Closed-Sourced folks trust whatever gets shoved down your throat?
Re:CVS, huh? (Score:4, Insightful)
No. But I do check the md5 checksums that I get from at least 2 or 3 different sources.
So here's the funny thing about doing it that way. You're not necessarily any safer by doing that than just getting the binaries.
Why?
Unless you personally diff all the code that has changed since the last release, you don't know what's in there. Sure, you could check, and others can (and likely do), but you don't know until/unless they/you do.
So enjoy your security blanket, but realize that is is only that.
[/Rant]
Re:CVS, huh? (Score:4, Insightful)
The grandparent said he checks at least 2 or 3 sources. This means all the sources would need to have the same hacked copy. That means the attacker would have either had to have nailed the server distributing the copies (and the people there would have had to have been dumb enough to go ahead with it) or by luck have comprimised all of these random servers.
So enjoy your security blanket, but realize that is is only that.
Although the situation I described above is certainly possible, I would say the grandparents method is good security practice and probably a lot more than a mere "security blanket". That is, if I'm correct in my reasoning. If not, I'd appreciate comments.
Re:CVS, huh? (Score:4, Funny)
And how are they going to do that? Through a hole in something like CVS??? Couldn't be!
Re:CVS, huh? (Score:3, Insightful)
no shit! Don't quote me out of context. I had some more following that. My original quote:
That means the attacker would have either had to have nailed the server distributing the copies (and the people there would have had to have been dumb enough to go ahead with it)
and also...
Although the situation I described above is certainly possible, I would say the grandparents method is good security practice and probably a lot more than a mere "security blanket".
So... I sincerly hope that the people distributing the release:
and, of course,it's still possible that this could happen. Certainly. I never said it couldn't. That dosn't change the fact that checking multiple sites will probably take care of most of these CVS attacks, since it's a lot easier to hit one random mirror than the main fucking site.
Re:CVS, huh? (Score:5, Funny)
No, but we swallow it anyway, lol.
-
Re:CVS, huh? (Score:4, Insightful)
you sir, are an ass (albeit anonymous)
what good does getting the md5s do? so you get your sources from 2 or 3 places
It works when one of the CVS servers you're downloading from gets hacked. Of course it's possible for the distributing server to get hacked too, but I'd hope people are watching it a bit more keenly. If the developers don't have more than one copy of their own code with which to check before submitting their release to the mirrors, then they shouldn't be making OSS software.
This is still much much much much better than doing nothing. You can never be 100% secure. Security is doing all the reasonable things you can to approach 100%.
maybe the transfer from master to mirror mixed up a few bytes.
Then the MD5 sum will be fucked up. What's your point?!
maybe all your downloads from a mirror mixed up a few bytes
In the exact same way ?! if the file is only a megabyte then the chances of this will be slimmer than 1 to 1 million squared! Either way the MD5 sum, since it's independant of the data, will be fucked up.
either way, it doesn't matter how many sources you use to d/l source packages for 'safety'
Maybe if you've never taken a statistics class.
oss needs a better method of s/w distribution. sign packages and their md5 hashes with pgp would be a start.
Um... there are OSS distribution rules? It's up to you to judge the competency of individual projects, as far as security goes.
Oh, and why is this OSS's problem? Why isn't closed-source even MORE vulnerable to this phenomena? OSS developers aren't the only ones who use CVS internally.
Re:CVS, huh? (Score:5, Insightful)
Re:CVS, huh? (Score:5, Insightful)
The question then becomes, "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."
GPG. Know it. Live it. Love it.
Re:CVS, huh? (Score:2, Informative)
"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.
Re:CVS, huh? (Score:2)
It's not like hundreds upon hundreds of people have commit access to a project like JBoss... or Ant... or Apache... There are relatively few committers, and each of those has generally earned some amount of trust from the maintainer of the project. And those people I'm trusting are easily identifiable to me...
who is administering the server where I can download Apache? I have no friggin clue.
So, I can trust a small group of people who have the earned trust of the person willing to sign their name to it, vs trusting an unknown number of people, or a sysadmin who used his mother's maiden name as the root password to the server he's administering.
Not the same thing at all.
Re:Er.... (Score:3, Funny)
Yeah, and we need to quickly find a way to blame Microsoft for this CVS bug. Any ideas?
Chicken and egg problem? (Score:5, Funny)
Re:Chicken and egg problem? (Score:5, Informative)
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 [acm.org] 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.
Re:Chicken and egg problem? (Score:3, Insightful)
Now, the way to prevent this from happening is to use a compiler other than gcc when compiling gcc. Then, the hackers would have to hack both compilers, which would be a much more significant task.
Are there any really paranoid folks out there that build gcc with the Intel compiler or somesuch? Is it possible to build gcc with another compiler?
Btw, when the russian hackers hacked Microsoft, how do you know they didn't do this to VC++?
/POSSIBLE/? Jeez... (Score:5, Interesting)
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.
Whaddya mean, "imagine"? (Score:3, Funny)
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.
Re:Chicken and egg problem? (Score:2, Informative)
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!)
THE PATCH IS WRONG (Score:3, Informative)
The patch from e-matters does NOT fix the double free bug!!!!
the great circle of software.life (Score:4, Funny)
exploit, patch, exploit, patch, exploit, patch.
insert elton john music here
It's true (Score:5, Funny)
cvs as root? (Score:5, Interesting)
Re:cvs as root? (Score:5, Interesting)
Remember, many sys admins don't patch local software packages that have buffer overflows or other wonder exploits that can get you root, so just about ANY remote exploit that you can get shell access with can be viewed as a root exploit. This is especially true with University servers and other places that install all software packages that come with their Linux distribution in the name of "research" or "education".
Just my $0.02 cents
Local Exploits (Score:2)
Re:cvs as root? (Score:2, Funny)
Then they'd do this with apache, cvs, sendmail, bind, etc.
Am I wrong in assuming this?
Re:cvs as root? (Score:5, Informative)
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
Re:cvs as root? (Score:3, Informative)
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.
Malignant users? (Score:4, Funny)
Cripes, it's time to ban C (Score:4, Insightful)
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?
Re:Cripes, it's time to ban C (Score:5, Insightful)
Or maybe not - someone will find a way to exploit those and anything alse that catches on.
It's impossible to protect non-trivial software from *everything*. You might as well get on with your life, plan for exploits and how to deal with them. Anything else is just a pipe dream.
That's silly (Score:3, Insightful)
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.
About Tradeoffs (Score:4, Insightful)
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.
Agreed. However (Score:3, Insightful)
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.
Re:About Tradeoffs (Score:3, Insightful)
Re:That's silly (Score:3, Interesting)
Dropping C because it's susceptible to exploits is dumb, as is replacing it with some other technology that will eventually be hacked anyway.
Re:That's silly (Score:3, Insightful)
Actually, it's like saying automoviles and airliners cause far too many deaths, so let's stop using them and just walk.
The reason we continue to use automobiles and airliners is because they can get us places that walking cannot practically get us. The original poster admitted that C should be used when it is necessary. But he pointed out that it is used way more often than is necessary at a terrible consequence to our security. He specifically outlined a plan wherein we use C for what it is good for (performance) and use other things for what they are good for (security).
Dropping C because it's susceptible to exploits is dumb, as is replacing it with some other technology that will eventually be hacked anyway.
It isn't that C as a technology was "hacked". It is that C as a technology has a design that makes it more vulnerable than other technologies. Those other technologies will also be hacked but less often. That's a net win even if it doesn't eliminate hacking in total (which is a silly goal in the first place).
Re:Cripes, it's time to ban C (Score:2, Informative)
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 /. [slashdot.org]
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.
Re:Cripes, it's time to ban C (Score:2)
Not really =) The fact that the bug is unintentional (and I've never heard of an intentional bug, but still) is irrelevant because it's still a potential exploit. The fact that it's cause by a malloc error is irrelevant, because it's still an exploit.
If you write software in C, you need to follow a certain set of rules to prevent things like these from happening. If you were writing something like CVS in Java, you'd have less things to worry about and you'd probably be more productive, but that doesn't mean that having a huge runtime saves you from having to think about security. Further, larger swaths of the application domain are taken away from you (nee runtime) so you're at the mercy of hackers who find an exploit in the Java IO package and you still need to wait for Sun to patch it.
But the bottom line is you'll never have a 100% exploit-proof application, period. It doesn't matter what you write it with. What you need to do is choose the right tool for the job, follow standards and guidelines, incorporate security into your design from the start and do your best. And then have a plan to deal with the eventual exploit. Because, believe me, you'll have one if your software is used widely enough, as is CVS.
Re:Cripes, it's time to ban C (Score:2)
Another alternative is RCS written on shell: Arch [gnu.org].
Wait, both Scheme and Shell are written on C, so you can't use them either. You may try to find someting written directly on Asm.
Re:Cripes, it's time to ban C (Score:3, Insightful)
It's not the language, it's the coder. Just like it's not the car, it's the driver, if someone causes an accident. Replacing every sports car with a Kia isn't going to stop accidents. Educating drivers on good practices is.
Uhm, no shit? I think you should write a book! Seriously, saying that there should be code reviews before software gets deployed? That's an awesome idea, I think I'll start implementing it into my own development.
Again, the problem is not the language, it's the coder. People make mistakes, languages do not (compilers on the other hand). Don't blame a language for operating exactly as it's designed to.
You can do garbage collection in C just fine, with external libraries.
Re:Cripes, it's time to ban C (Score:2)
Same way, manual operations with memory ponters must be prohibited. And they are prohibited in languages with garbage collectors and automatic memory allocation: Java, Python, Perl, Ruby.
GC, automatic memory allocation and disabled GOTO, such methods limit programmers (in a positive way) and help to avoid very critical mistakes. But not all mistakes. Changing the variable (object) value is another source of common mistakes, which must be eliminated. It's solved [chalmers.se] in Functional Programming [nott.ac.uk] languages, such as Lisp, Haskell, ML, Oz, Mercury and Erlang.
What's wrong with GOTO? (Score:2)
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!
Re:What's wrong with GOTO? (Score:2)
-sirket
Re:What's wrong with GOTO? (Score:2)
Ummm... "call" is just "push ESP; goto $ADDRESS_OF_SUBROUTINE"
"jne" is just "if !(flags ~ 0x0010) goto $ADDRESS_OF_THEN_CLAUSE"
Re:What's wrong with GOTO? (Score:2)
Sometimes I feel very, very old. This one reminds me about Zaphod Beeblebrox and the accident with the contraceptive and the time machine. LISP was written in 1958, one of the oldest high level languages for programming. BCPL (on which C is based) was written in 1967, and C was written in 1971. So are you trying to tell me that John McCarthy [stanford.edu] wrote LISP [stanford.edu] in a language which wasn't even going to be devised for another twenty three years? That was extremely clever of him.
Re:Cripes, it's time to ban C (Score:2)
2) Lisp is not the same as functional programming. Although it encourages a functional style, it has numerous procedural elements. Variable assignment is NOT functional programming, and Lisp is not the ultimate FP language.
Re:Cripes, it's time to ban C (Score:2)
Most functional languages are not ONLY functional (Score:2)
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.
Re:Cripes, 's time to ban C (Score:2)
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.
Re:Cripes, 's time to ban C (Score:2)
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.
Yes, blame the language! (Score:2)
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!)
Re:Yes, blame the language! (Score:3, Informative)
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.
Re:Yes, blame the language! (Score:2)
> 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.
I think you must have never written any big software, because it's not as simple as you think. 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.
Now, if we always go to so much trouble to look for bugs, and always use functions that check bounds, then why not simply have the language (compiler) do this work for us? This can free us to spend more time doing things that are not totally mechanical (looking for other kinds of security holes) or useful (looking for ways to make the program better). What is wrong with my reasoning?
> 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.
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.
Re:Yes, blame the language! (Score:3, Informative)
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.
Re:Yes, blame the language! (Score:3, Insightful)
> 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??
Re:Yes, blame the language! (Score:3, Insightful)
> 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.
Re:Cripes, it's time to ban C (Score:4, Insightful)
But, banning C is the LAST thing you'd want to do in a case like this. 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 ...) does. Switch over to a "safer" language (Java, Perl, whatever) and the commands to run the connection will be safer, but the server as a whole will suffer - and thus less people will use it.
The best case here would probably be to set up two layers - a Perl wrapper that parses and verifies input before passing it on to a C program that actually does the serving. But this is a server - emphasis on the C core, not the Perl wrapper. The parsing/verify is the special case, while the data transfer is the general case, and so designing for the general case makes the language of choice C.
But getting back to the topic, the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug. Global variables are bad in general, and should only be used with due diligence - and here's simply a case where that diligence didn't work.
Re:Cripes, it's time to ban C (Score:2)
I don't think that stacks up. Apache Tomcat is actually very high performance, nearly as fast as Apache itself I've been told by people who would know.
I was having this argument with a friend last night. He couldn't understand how Java could be faster than C, so I showed him the HotSpot whitepaper.
But getting back to the topic, the bug here isn't a memory management bug. It's a flawed PROGRAM design that RESULTS IN a memory management bug. Global variables are bad in general, and should only be used with due diligence - and here's simply a case where that diligence didn't work.
No, it's a memory management bug. If the CVS server has a poor design that's a separate issue, but manual memory management is a pain in the ass and very easy to get wrong. Considering how many servers are in fact written in Java and their ilk, I think a possible slight loss in speed is certainly worth the increased security.
Re:Cripes, it's time to ban C (Score:2)
Sun seems to continuously pull off miricles with Java. Humbug. :-) But in all seriousness, I think it might be worthwhile to consider memory load (and the associated problems with running out of memory, using swap, etc.) in the term "performance" (yeah, I have to pick on Java's weakness to get anywhere...).
But I also happen to think that Java itself isn't that far removed from straight C++, it can be about as efficient algorithmically and so any debate devolves into inefficiencies of garbage collection versus advantages of HotSpot. Of course, all this assumes good C++ coders and good Java coders!
It's still poor design. Java could have a similar bug - an old pointer in a static class. It wouldn't create an exploit (I agree), but it would likely throw a null pointer exception or cause data corruption. And I'll lump good Java exception handling right there with manual memory management in terms of difficulty. Not just catching the exception, but handling it in a fail-safe way.
Uninformed! Yes, let's please move on from C! (Score:5, Informative)
- "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.)
Re:Uninformed! Yes, let's please move on from C! (Score:2)
Crashing a computer, or otherwise rendering it useless, is the basis of many many attacks which occur on the internet every day. We call them "Denial of Service" attacks, or DoS. I'm surprised you haven't heard of them. It is true that being crashed is better than being compromised, though.
While this does seem true, it also seems to me that it's mostly a result of various deprecated libraries still being used. Not enough thought went into designing a lot of the string functions, obviously; they look like something you'd write in assembler, what with no bounds checking. Even when I wrote asm I terminated all my strings with nulls and specified lengths, and this was just for a class. C may not manage memory very well, but there seem to be a handful of rules which you can follow which will prevent shooting yourself in the foot with what happens to be a very useful gun.
Re:Cripes, it's time to ban C (Score:2)
Re:Cripes, it's time to ban C (Score:2)
It's distressing how many people criticize C without understanding the issues.
Formally, when you use a pointer outside the bounds of the object it points to, the behavior is undefined. This is why your old MS-DOS compilers happily trample all over memory, but in many cases the same program will cause a "segmentation fault" or "general protection fault" on a better OS.
In other words, it's not a property of C that you are commenting on, rather the quality of implementation that compiler writers chose. You can, in fact, write a standard-conforming C compiler that catches every illegal access. It will likely be somewhat slower, and may not run some poorly-written programs.
Garbage collection is another question altogether. Garbage has nothing to do with security, but is of course crucial in a long-lived server. Use a malloc() replacement that has automatic garbage collection. Guarding against a duplicate free() is trivial when you need to do GC anyway. In fact, writing a replacement malloc() that tracks each block it gives out, a corresponding free() that only frees a block if it's on the block list, and a new collect_garbage() function that frees everything on the list will take you a couple of hours at most.
There's no need to throw away a language that so many programmers are familiar with, when it isn't even broken. Demand a safer compiler for server work, and replace a very small part of the library.
Finally, note also that C is a very popular language, and as such attract many people to it. This brings down the average quality of C code. A new language attracts a different set of people to it, and may initially have higher quality code written for it. However, as the new language becomes popular, the same thing could happen. Be careful not to blame the language for this, or you'll be chasing that "better" language endlessly.
Interpreted C versus new languages (Score:2)
I think you're technically correct about being able to faithfully (in terms of the standard) implement C while providing "safe" termination in common undefined behavior situations. I'll bet there are some corner cases where it wouldn't work, but it would be good enough to make software much safer. Your implementation would be slow as hell, though, because essentially you'd have to write a C interpreter. The most difficult part is pointer arithmetic, since it's not clear where you place the tag that says how big the memory to either side of the pointer is. The only way to do this is probably to use "fat pointers", so that pointers are actually data structures that themselves include this information.
Writing a malloc replacement that guards against duplicate free()s is not as trivial as you think. I don't think it can be done as a little library unless your pointers carry extra info or your malloc() never returns memory that was handed out before. (Consider the case where you have two copies of a pointer, free one, and then later malloc and receive the same (reused) piece of memory.)
Here's the problem though: Slow as hell might be good enough for network servers, but it's not great, and that will turn some people off from the idea. We can get quite good performance, however, if the language is simply designed to provide safety from the start. (I was able to get within 20% of C speed with SML on some highly C-biased benchmarks, and it was never worse than 2x slower). Perhaps the right thing is instead to provide safe (but compiled) C-like languages? Java? Popcorn? Cyclone?
Just one thing to add: I've looked through the code to some of these common linux servers, and much of it is pretty awful. I don't think keeping around legacy code is necessarily an advantage to your proposal -- rewriting software is not that hard once you know what it's supposed to do, and the result is usually much nicer.
Re:Cripes, it's time to ban C (Score:2)
Re:Cripes, it's time to ban C (Score:4, Informative)
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.
Re:Cripes, it's time to ban C (Score:2)
guess what language perl is written in? yeah thats right, C. Guess what, if you work really hard, you can make perl have a buffer overflow (or at least segfault).
also, if you use proper techniques when programming c, its not that hard to avoid buffer overflows and malloc problems.
Re:Cripes, it's time to ban C (Score:2)
How are they going to fix that one. (Score:2)
Re:How are they going to fix that one. (Score:2)
Don't know if it's a hoax (Score:2)
Re:How are they going to fix that one. (Score:2)
Maybe, maybe, not. It depends on the nature of the bug. But even if the resulting compiler came out faulty it is very unlikely that it would be exactly the same problem as before. It can be done intentionally [acm.org], but doing that by mistake is just too unlikely.
to be notified next time around do this: (Score:5, Informative)
echo 'subscribe security-announce' | mail majordomo@openbsd.org
I think Bug applies to Windows... (Score:5, Interesting)
Last week I installed CVS and opened a public server. A couple of days later one moment to the next I was locked out of my machine. I was thinking, huh? What happened here. Well what happened is that my administrator account was locked and all users had their rights reduced to user. In other words I had a locked out machine since the administrator could not be unlocked. I ended up paving the machine and installed Linux. Actually I am thankful for that since the Linux install worked out well.
Re:I think Bug applies to Windows... (Score:5, Funny)
Did it go like, "beep! beep!" at all?
Re:I think Bug applies to Windows... (Score:3, Insightful)
You cannot "lock out" the Administrator account in such a way that prevents you from logging on. The account will be flagged as being "locked out", but you are not prevented from logging on with it. This is to avoid the exact bullshit scenario you describe above. The local "Administrator" even when renamed (good idea) is the only account that behaves this way.
You can test this yourself by going to Administrative Tools - Local Security Policy - Account Policies - Account Lockout Policy, and set the rule: "Account lockout threshold" to 2 or 3 or some non-zero low number. Go ahead and try. Just make sure you have another local-admin account in case I am trying to trick you
Of course, you will not be able to change the local Account Policy if your machine is in a domain that already has that rule defined and you are/are unwilling to change the domain policy.
I believe that you might be one of the many incompetent Windows administrators that have helped to give it such a bad name. I'm not saying Windows is perfect, but when the evil empire distributes FUD there are plenty here to say so. I'm just setting the record straight here to prevent the disemination of bogus information. Shame on you.
Re:I think Bug applies to Windows... (Score:2)
I was locked out of my machine locally. I could not log in locally, remotely or even at the console recovery window. Initially I tried at the console recovery window to copy the SAM database. I tried using a couple of tools at the command line level in the console and NOTHING worked. I was locked out! And if you did not catch it, my other users were stripped of their admin levels. As I always keep one user at the admin level for situations like this.
Then I talked to a very knowledgable Windows Admin who manages large farms of Windows boxes in a critical environment. His conclusion is that it can occur and the only way to go back is do a backup rollback. That way the system goes back to a previous state.
So next time, do your homework a bit and you will see that indeed that you can be locked out!
Paraphrasing... (Score:2, Funny)
Several months, E-matters was recruited by the RIAA (riaa.org) to invent, create and finally deploy the future of antipiracy tools. We focused on creating virii/worm hybrids to infect and spread over a diversity of version control programs.
Until we became RIAA contracters, the best they could do was to passively
monitor traffic. Our contributions to the RIAA have given them the power
to actively control the majority of hosts used for developing software.
(for the rest of the message, please see the original post [securityfocus.com].)
Not necessarily a root hole. (Score:5, Informative)
Todd Miller just sent this to the OpenBSD security announcement list. It doesn't sound like it's a root exploit (at least on OpenBSD [openbsd.org]).
OpenBSD anoncvs mirrors should not be affected by this since cvs is run in a chrooted environment where the anoncvs user does not have write permission.
isn't this overblown? (Score:2, Informative)
username1:encrypted_password:cvs
which means, accept logins as username1 but run as cvs. It works just fine - why would anyone need to run it as root again? Oh yes I see - it's easier for admins to say: yeah access everything.
Re:isn't this overblown? (Score:2)
when such things happen, its not a bug in the software, its a bug in the kernel
This is somehow (Score:2, Funny)
Anyone else see the note at the top of the patch?? (Score:5, Informative)
Re:Anyone else see the note at the top of the patc (Score:2)
But its still very very funny to see that comment up there.
Re:Anyone else see the note at the top of the patc (Score:2)
I wonder... (Score:2, Funny)
I think the admin only knew windows. Maybe i should call him back and ask if he knows how to patch the server?
Oh well.. Just drunken rambling after bar. I think the machine was NAT'd anyway.
(Which reminds me. The suckers had paid something like $10.000 for their NAT system, and on a closer inspection, I could have replaced the device with a crappy $500 Lunix box)
quick fix (Score:5, Informative)
--- server.c- Fri Apr 28 15:37:13 2000
+++ server.c Fri Apr 28 15:38:06 2000
@@ -4553,8 +4553,6 @@
REQ_LINE("Max-dotdot", serve_max_dotdot, 0),
REQ_LINE("Static-directory", serve_static_directory, 0),
REQ_LINE("Sticky", serve_sticky, 0),
- REQ_LINE("Checkin-prog", serve_checkin_prog, 0),
- REQ_LINE("Update-prog", serve_update_prog, 0),
REQ_LINE("Entry", serve_entry, RQ_ESSENTIAL),
REQ_LINE("Kopt", serve_kopt, 0),
REQ_LINE("Checkin-time", serve_checkin_time, 0),
CVS hosting? (Score:3, Interesting)
Can anyone recommend a CVS hosting provider? Hopefully for not too much more than web hosting. Last I looked, this didn't seem very widespread -- or at least, not widely advertised.
(Yes I'm aware of Sourceforge, but the project in question isn't "free software" -- not that it ain't free, but it's not really software.)
Minor Inconvenience (Score:2)
Debian? (Score:2)
apt-get update
apt-get upgrade cvs
Debian decided to upgrade 20 packages, including libtimedate-perl and twig (our webmail app)?
Why does it need to pull down 5 megs of packages to upgrade a security fix in CVS?
Re:Debian? (Score:3, Informative)
upgrade
upgrade is used to install the newest versions of all packages currently installed on the system from the sources enumerated in
apt-get upgrade takes no arguments, unlike install
Re:Debian? (Score:4, Informative)
BTW, if there are 20 packages to upgrade you haven't run it in a while, so it's a good idea to get all those bug fixes anyway.
Quick Question: 'cvsd' Users Affected? (Score:5, Interesting)
This would explain why, after returning home from a week away in Atlanta, my server/gateway was powered off. The logs suggest this happened on 20 Jan, the day I returned. I'd assumed there had been a power failure while I was away, but none of the clock were blinking 12:00. It was very puzzling until I read this report.
I am running my CVS repository on a FreeBSD box using a little utility called cvsd [tudelft.nl], which establishes a setuid() and chroot() jail for the repository. I chose to do this as I'd read a number of past horror stories about CVS servers being compromised, so this seemed a prudent tactic, especially for a new CVS administrator such as myself. If I'm reading the vulnerability report correctly, all that might have been compromised is my repository tree. It seems, though, that the presumed attacker managed to crash my machine to power-off state (how?); the filesystems needed to be fsck'ed while rebooting.
I admit to being a relative novice when it comes to system administration, and I'm even newer when it comes to CVS administration (the CVS wrapper/daemon had only been running for about 2-3 weeks before this happened). Still, I'm at a loss to explain how a crash-to-power-off could have happened on a *BSD box any other way, especially in light of this vulnerability being revealed less than 24 hours later.
All opinions on this event are welcome. In the meantime, I'll be staring at my box good and hard.
Schwab
Re:Quick Question: 'cvsd' Users Affected? (Score:2)
BTW, if anyone knows of any tools to check CVS repository integrity, let me know. Thanks!
Waiting patiently for Subversion to get stable :-),
Schwab
Re:Quick Question: 'cvsd' Users Affected? (Score:2)
The precautions you took to secure your CVS daemon should be pretty adequate for keeping it contained in the event it was compromised. I would look at your powersupply if I were you. Is it on a UPS? Some older ATX powersupplies (iirc) would shut off or turn on spontaneously from brownouts or power spikes.
Just a thought.
Re:Malignant? (Score:2)
Re:Malignant? (Score:4, Interesting)
Re:This CVS exploit is another reason Mac's secure (Score:2, Interesting)