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."

Comments

CVS, huh?

[stratjakt]

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?

Re:CVS, huh?

[penguin_punk]

"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?"

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?

[Monkeyman334]

First, the bug being in CVS has nothing to do with changing the source code on a hacked machine. If you have root from ANY bug, you can change the source code. No, "OSS folks" do not waste time looking through every bit of source of Apache, Squid, or SAMBA, if they're just downloading and compiling it on a machine that's been compromised. They probably couldn't find malicious code anyway if they don't know the code well. They just run md5 hashes against the ones on the download site. As for developers checking code that they developed themselves or distribute, yes, you must check every line of code and look for vulnerabilites. That is, unless you have some backup to run a diff against that you can trust. As an example, Themes.org had to go through all their code when their server was compromised before they put the site back up.

Re:CVS, huh?

[guido1]

[Rant]

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?

[bokmann]

No, but plenty of open source projects 'sign' their work, which I can then verify with gpg and the public key of the developer(s).

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?

[feed_me_cereal]

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.

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?

[feed_me_cereal]

you sir, are an idiot.
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.

Cripes, it's time to ban C

[phr2]

I looked at the advisory expecting to see the words "buffer overflow", and instead saw "malloc mistake" (same pointer can get freed twice in some circumstances). Both of these amount to the same thing, getting nailed by C's lack of automatic memory protection and garbage collection.

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

[The Bungi]

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.

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.

Re:Cripes, it's time to ban C

[kscguru]

Ah, but the phrase that jumped out at me was "global pointer variable" - a synchronization-type problem that could hit just about any language (yes, Java included). 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?

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.

About Tradeoffs

[kscguru]

But it's also like saying that fatal accidents are more common when cars are travelling above 40MPH, so we'll add a device to prevent high speed - oops, your house burned down because the fire truck couldn't get there in time? Sorry, hope the decreased risk of an accident was worth it. Or, saying that your seat belt is so heavy that your car only goes half as fast - not such a good deal anymore, is it?

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.