New rsync Released to Fix Vulnerability

Gentoo by lisany · 2003-12-04 14:32 · Score: 5, Informative

This is what got the cracker in (plus the brk kernel thing) into the Gentoo Rsync server. All fixed now tho!

Re:Gentoo by keesh · 2003-12-04 14:34 · Score: 4, Insightful

That's, what, 24 hours or so from the attack to a full patch to a previously unknown exploit being released? Gotta give those Gentoo guys some credit, that's damned impressive...
Re:Gentoo by TheIzzy · 2003-12-04 15:44 · Score: 5, Insightful

Hello?
Security breaches happen. Even on OpenBSD and other "secure" systems. If you looked into the event at all, you would see that Gentoo did indeed have excellent security counter measures in place. No amount of firewalling is going to stop an *unknown* vulnerability from being exploited. No amount of security auditing is going to find *every* exploit in code as complex as gentoo's. The fact that the compromised server could be restored, and the compromising code be analysed and fixed within twenty-four hours is very impressive. If anything, this is a testiment to the security at gentoo.
If I were a CTO or someone who was checking to make a switch, this would be very impressive. I don't, however, think this is gentoo's target audience. But I do know that Microsoft definitely does not have turn-around times that impressive.

chroot by larry+bagina · 2003-12-04 14:36 · Score: 4, Insightful

The server that was compromised was using a non-default rsyncd.conf option "use chroot = no". The use of this option made the attack on the compromised server considerably easier. A successful attack is almost certainly still possible without this option, but it would be much more difficult.

Maybe I can't see the forest for the trees, but why would you NOT want to be chrooted?

--
Do you even lift?

These aren't the 'roids you're looking for.

Re:chroot by syntax · 2003-12-04 14:37 · Score: 4, Insightful

How about complete remote backups of the root file system?
Re:chroot by toast0 · 2003-12-04 15:14 · Score: 3, Informative

use the --perms option to rsync

from the manpage:

"This option causes rsync to update the remote permissions to be the same as the local permissions."

RTFM

--
Need a Catering Connection
Re:chroot by Saganaga · 2003-12-04 15:15 · Score: 3, Informative

rsync --help
Options ... -a, --archive archive mode, equivalent to -rlptgoD ... -r, --recursive recurse into directories -l, --links copy symlinks as symlinks -p, --perms preserve permissions -o, --owner preserve owner (root only) -g, --group preserve group -D, --devices preserve devices (root only) -t, --times preserve times -S, --sparse handle sparse files efficiently ...
So in other words, you want to use option -p. Or why not just use -a as the docs suggest?

Workaround by elvum · 2003-12-04 14:36 · Score: 3, Informative

...or just don't run rsync as a server. There's no need to for most uses anyway - just install the client at both ends and connect with the "-e ssh" flag and you're laughing.

Re:Workaround by pHDNgell · 2003-12-04 15:04 · Score: 4, Interesting

or just don't run rsync as a server. There's no need to for most uses anyway - just install the client at both ends and connect with the "-e ssh" flag and you're laughing

What if I don't want system users for every rsync user? What if I need to run my connections through an http proxy server (yes, I really, really do)? What if I want standard mechanisms for listing available modules? What if I want to limit the number of simultaneous connections for a specific area? What if I want to limit the files available in a specific area? What if I want to transfer sensitive files on a system periodically from cron, but I don't want to have an ssh key that grants access to do this without a password on the recipient machine?

I think that pretty much sums up the ways I most commonly use rsync around the house. I do use it with the -e ssh option for one-off things sometimes as well, but not running a server is certainly no workaround for me.

--
-- The world is watching America, and America is watching TV.

rsync by Anonymous Coward · 2003-12-04 14:39 · Score: 5, Funny

News Flash:

rsync releases a patch and changes its name to r'sync. The change is noted to increase its name recognition in the teenybopper script kiddie market. At this point, no pimply-faced l337 d00dz will dare deface r'sync for fear that they will be further alienated by the female species.

Unfortunately, timberlake and FatOne continue to be backdoored.

Re:rsync by prog-guru · 2003-12-04 15:00 · Score: 5, Funny

Rsync is also the preferred transfer method of pirates, software and treasure hunting ('arrr sync').

--
chris@xanadu:~$ whatis /.
/.: nothing appropriate.

Credits by Anonymous Coward · 2003-12-04 14:41 · Score: 4, Informative

Credits
-------

The rsync team would like to thank the following individuals for their
assistance in investigating this vulnerability and producing this
response:

* Timo Sirainen

* Mike Warfield

* Paul Russell

* Andrea Barisani

Regards,

The rsync team

http://lwn.net/Articles/61541/

this is why i dont use any package management by n0k14 · 2003-12-04 14:59 · Score: 3, Funny

i do it the slack way.

arg. by mikeee · 2003-12-04 15:00 · Score: 4, Funny

Of course, to patch this, you should go to your local mirror, which will be down until they patch the rsync vulnerablity...

Doh!

Package Download by Hal+The+Computer · 2003-12-04 15:03 · Score: 3, Interesting

Instructions on how to update Slackware to the latest and greatest rsync are at:
http://slackware.com/security/viewer.php?l=slackwa re-security&y=2003&m=slackware-security.399741
Of course if you're running a server you should theoretically be subscribing to the security mailing list. Right?

--

int main(void){int x=01232;while(malloc(x));return x;}

Re:Eh? by uncleFester · 2003-12-04 15:03 · Score: 5, Informative

Nobody runs rsync as a publicly accessible service anymore.

oh really?

i rsync my local copy of slacware-current from carroll.cac.psu.edu. probably half the listed servers on the slack mirrors list (many of which host many other projects besides slack) do rsync. gentoo uses rsync for portage. kernel.org supports rsync for kernel/patch transfers.. as does sourceforge.

me thinks thou should pull thine head out of thine ass before making such silly comments. for a number of read-only connections, rsync is still quite popular.

--
-'fester

FSF Savannah Server Compromised by molo · 2003-12-04 15:05 · Score: 5, Informative

The FSF Savannah server has been hacked. The statement indicates a similar attack vector as the exploit against the Debian systems. However, it had been hacked nearly a month ago and was not detected until December 1st. For those that are not familar with it, Savannah is the FSF version of Sourceforge, hosting both GNU and non-GNU Free Software projects. It has not yet been determined whether any of the projects' source code has been modified. Read the full statement for details. One thing is certain though, with Debian, Gentoo and now the FSF being exploited in the same month, the open source/free software community is clearly under attack.

--
Using your sig line to advertise for friends is lame.

Re:So... by Anonymous Coward · 2003-12-04 15:15 · Score: 5, Insightful

It took the Debian developers over a *week* to find the cause of their servers being rooted, but Gentoo is able to accomplish the same in one day, *and* provide a fix?

It seems obvious where the real talent in the Linux community lies today.

In case you hadn't noticed, the Gentoo developers based their analysis on the Debian developers' work. The real talent in the Linux community lies in the community.

Re:Rsync Protocol Was a Bad Idea by Qzukk · 2003-12-04 15:21 · Score: 5, Informative

What's the point of another network protocol

Unlike ssh, rsync daemon doesn't require a user on the host system. Unlike ftp or http, rsync updates by splitting files into blocks and updating changed blocks. Unlike scp, the config file can exclude/include certain files/paths/etc. without requiring the use of filesystem permissions. (it also has password protection).

Does anyone know of a program similar to rsync

Nah, there wasn't a point to it.

--
If I have been able to see further than others, it is because I bought a pair of binoculars.

PGP-sign everything by Meat+Blaster · 2003-12-04 15:22 · Score: 4, Insightful

I see too many packages out there that have no meaningful way to verify their contents. I've felt for a long time that this was something that was going to come back to haunt us.

I hope that this will provide more incentive for Open Source programmers and Linux distributors to properly secure their releases. This entails ensuring that from the time a package leaves a maintainer to the time it reaches a user there should be no possibility of tampering.

Authors/maintainers need to generate PGP keypairs and start signing their archives. MD5 checksum distributed alongside the package does not cut it -- how are we to know the package wasn't tampered with and a fresh checksum generated? No, the only way we can really feel secure is to have authors use PGP on a regular basis to verify their work, and to integrate public key/private key into CVS in order to have submitters automatically sign their changes to the source.

Then things like the Savannah hack and the various mirror compromises will only be a black eye instead of a serious threat to the Open Source methodology.

Re:PGP-sign everything by giminy · 2003-12-04 18:32 · Score: 4, Insightful

Hear, Hear. Along the same lines, it's pretty important that they sign with a key in the strongly connected set. I've seen a lot of projects that actually provide PGP sigs, but the keys used to generate the sigs don't have any signatures, or are part of closed (2-3 key) set! This is about as useless as MD5 checksums, imho. It's very easy to generate a key with Linus Torvalds as the name, but very difficult to get people in the strongly connected set to actually sign it...

--
The Right Reverend K. Reid Wightman,

Re:Rsync Protocol Was a Bad Idea by CheshireCat · 2003-12-04 15:26 · Score: 4, Informative

CVS and rsync are different applications with different uses.

CVS maintains a history of all revisions made to the files in the repository. It doesn't even have a means to synchronize clients without a versioned repository on the server, it relies on the server knowing all past revisions to determine which changes to send to the client.

Rsync works with plain files on the server, not RCS. if you *need* revision control, it's useless, but if you only want to be able to synchronize client files to match the files on the server, it's much better than CVS. The server saves space and complexity by not having to do revision control, and the client still gets the benfits of the server only needing to transmit the changed portions of files.

I would just like to say... by LnxAddct · 2003-12-04 15:28 · Score: 5, Informative

For all you naysayers who always talk trash about Fedora, I run fedora and debian and fedora alerted me this morning about the problem and patched it in seconds. I updated debian too, but I usually dont update on a daily basis, usually like once a week or something, unless I see something in the news. I would have had no clue about this for about a 3 days if i hadn't read slashdot and didn't have Fedora to alert me. I personally like Debian better for other reasons, but I'm just saying dont bang on Fedora, its a damn good product.

Re:I would just like to say... by Mr.Ned · 2003-12-04 18:47 · Score: 4, Informative

> I would have had no clue about this for about a 3
> days if i hadn't read slashdot and didn't have
> Fedora to alert me.

Why don't you subscribe to the Debian security announcement list? It is a very low-traffice list and you will get an e-mail as soon as an updated package is available.

By the way, for your interest, here are the times on the rsync e-mails to bugtraq today (in my time zone):

Slackware: 2:50AM
Debian: 11:09AM
SuSE: 12:14PM
Gentoo: 3:13PM
Connectiva: 3:46PM
Red Hat: 4:14PM

Some history.. by cras · 2003-12-04 15:55 · Score: 5, Interesting

Two months ago I found the problem and gave a patch to fix it. Looks like the bad guys were smarter than I thought and figured out a way to exploit it. Lesson: release fixes for even potential security holes immediately :)

Re:Rsync Protocol Was a Bad Idea by Zork+the+Almighty · 2003-12-04 15:55 · Score: 4, Insightful

I don't know why they even invented an rsync protocol. - To efficiently synchronize a large amount of data over a slow connection. The algorithm is one of the fundamental gems of computing science, and I'm suprised you don't appreciate it.

--

In Soviet America the banks rob you!

Only affects Rsync servers by Blue+Booger · 2003-12-04 16:12 · Score: 3, Informative

(which is every open source mirror server out there, and many mirrors themselves)

No. This does not affect all the open source mirrors. It only affects rsync SERVERS. If you are not running rsync as a server, you are OK. If you are not accepting connections on 873 you are not running an rsync server. (Well, you could be, but you are probably running it over SSH, in which case you are still OK.)

--
--If you don't test it, it won't work. Guaranteed.

RedHat RPMs for fix by DDumitru · 2003-12-04 16:13 · Score: 4, Informative

RedHat has also released 2.5.7 RPMs for the fix.

When updating an older server (7.1, I think), the RH RPM failed with a GLIBC dependency. The updates for RH are identical for 7.1 - 9, so you might have a problem here.

My easiest workaround was to rebuild the rpm from source with:

Get the rsync-2.5.7-0.9.src.rpm from RedHat ftp server updates.redhat.com

Install the source rpm with:

rpm -ivh /tmp/rsync-2.5.7-0.9.src.rpm

Build a new complete, clean set of RPMs with:

cd /usr/src/redhat/SPECS
rpm -bb rsync.spec

The new installable binary for your current lib versions is in /usr/src/redhat/RPMS/i386, so you can install it with:

rpm -Fvh /usr/src/redhat/RPMS/i386/rsync-2.5.7-0.9.i386.rpm

---

For those that don't use rsync, this is easily one of the most useful utilities on the box. I particularily like "modules" mode over ssh. Setup an ssh key and have the key auto-run rynnc --daemon. You get modules and ssh. Really cool.

Re:rsync Protocol Was a Bad Idea by boots@work · 2003-12-04 16:50 · Score: 4, Informative

The network protocol it just something to get the (significantly reduced) data from point to point. There isn't too much a network protocol can do to speed up the process.

RTFM, idiot.

There are several things that a new network protocol can do to make a transfer faster. For example, rsync is heavily pipelined in both directions, and removes common information from headers of consecutive files. Neither of those optimizations would be possible in FTP or HTTP.

rsync was for years the only major application that aggressively utilized full duplex TCP sockets, and found several bugs in Linux, BSD, and Solaris kernels by doing so. Again this is a protocol design decision that gets more mileage out of the connection than is possible in other ways.

Have you ever even looked at an HTTP dump? The hundreds of bytes it takes to send the headers can accomodate several whole rsync-compressed files.
A recursive update of a changed tree is typically several times quicker with rsync than with either CVS or FTP. Nothing against those protocols; they were just designed with different purposes in mind.

Now you can reasonably question whether the space saving really justifies having a new protocol. If you're not convinced, don't run it. Many people do find it worthwhile. If you are super security-conscious then you probably shouldn't be offering anonymous or unencrypted service at all.

Slashdot Mirror

New rsync Released to Fix Vulnerability

29 of 226 comments (clear)