Slashdot Mirror
New rsync Released to Fix Vulnerability
cshields2 writes "Today the rsync developers have released a new version that fixes an exploitable security vulnerability when running rsync as an 'rsync server.' Any server out there running rsync should check this out and upgrade if necessary. (which is every open source mirror server out there, and many mirrors themselves)"
This is what got the cracker in (plus the brk kernel thing) into the Gentoo Rsync server. All fixed now tho!
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.
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.
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/
Of course, to patch this, you should go to your local mirror, which will be down until they patch the rsync vulnerablity...
Doh!
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
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.
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.
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.
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.
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.
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.
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.
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 :)
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!
RedHat has also released 2.5.7 RPMs for the fix.
/tmp/rsync-2.5.7-0.9.src.rpm
/usr/src/redhat/SPECS
/usr/src/redhat/RPMS/i386, so you can install it with:
/usr/src/redhat/RPMS/i386/rsync-2.5.7-0.9.i386.rpm
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
Build a new complete, clean set of RPMs with:
cd
rpm -bb rsync.spec
The new installable binary for your current lib versions is in
rpm -Fvh
---
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.
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.