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."
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!!!!
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.
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++?
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
> 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.
> 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.