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?

[Alsee]

Do you Closed-Sourced folks trust whatever gets shoved down your throat?

No, but we swallow it anyway, lol.

-

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?

[flynt]

That means the attacker would have either had to have nailed the server distributing the copies

And how are they going to do that? Through a hole in something like CVS??? Couldn't be!

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.

Chicken and egg problem?

[Gentoo Fan]

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? ;)

Re:Chicken and egg problem?

[pclminion]

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? ;)

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

THE PATCH IS WRONG

[Anonymous Coward]

cant you guys read? It is an additional patch!

The patch from e-matters does NOT fix the double free bug!!!!

the great circle of software.life

[poindextrose]

ah yes, another representation of sofware's circle of life.

exploit, patch, exploit, patch, exploit, patch.

insert elton john music here

It's true

[mao che minh]

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.

cvs as root?

[molo]

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.

Re:cvs as root?

[mustangdavis]

If I can get onto a Linux or BSD box as ANY USER, I can get root (well, 90% of the time, I can).

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

Re:cvs as root?

[jhealy1024]

What fool runs their cvs pserver as root?

Ummm... People using Debian?

On a stock Woody box:

grep cvs /etc/inetd.conf
cvspserver stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/cvs-pserver

Re:cvs as root?

[cras]

cvspserver stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/cvs-pserver

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?

[Dthoma]

I wonder how you operate to remove those?

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.

Re:Cripes, it's time to ban C

[HiThere]

Well, D comes to mind. So does Eiffel. And, now that gcj exists, Java. These are't real desireable languages, but they solve the buffer overflow/pointer freeing problem.

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 ... interesting.)

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:Malignant?

[jasonditz]

This is why I only offer access to benign users.

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.

Uninformed! Yes, let's please move on from C!

[Tom7]

This post is severely uninformed, like most others that defend C for network applications. Here's why.

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

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

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/to 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.

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

/POSSIBLE/? Jeez...

[devphil]

Is it possible to build gcc with another compiler?

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:

1. Your Proprietary Evil Compiler[tm] builds Copy #1 of gcc. However, YPEC could have bugs, which would make gcc#1 buggy. So...
2. gcc#1 builds itself from scratch. Call this one gcc#2. In theory, gcc#2 can now be used. But just to be certain...
3. gcc#2 builds itself from scratch. This is gcc#3. And if all is well, gcc#2 == gcc#3. So at the end, all of the various .o files from #2 and #3 are compared, and if there's a mismatch, the build aborts.

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.