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."
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? ;)
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.
"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?
HURD - Hurd's Under Research & Development
I wonder how you operate to remove those?
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
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.
[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]
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.
Do you Closed-Sourced folks trust whatever gets shoved down your throat?
No, but we swallow it anyway, lol.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
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.
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.)
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)