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!
...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.
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/
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
It doesn't look like ersync is open to this particular vulnerability. Although to my knowledge that doesn't run without chroot.
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.
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
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.
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.
Actually you should get your story straight it wasn't gentoo's server that got owned. It was a third-party server that among many things provides a mirror for gentoo rsync servers. This server is administred and run by a third party which is not linked to Gentoo.
(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 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.
here the security advisory of rsync.samba.org:
/etc/rsyncd.conf configuration file. If you are using the option
rsync 2.5.6 security advisory
December 4th 2003
Background
The rsync team has received evidence that a vulnerability in rsync was
recently used in combination with a Linux kernel vulnerability to compromise
the security of a public rsync server. While the forensic evidence we have is
incomplete, we have pieced together the most likely way that this attack was
conducted and we are releasing this advisory as a result of our
investigations to date.
Our conclusions are that:
rsync version 2.5.6 and earlier contains a heap overflow vulnerability that
can be used to remotely run arbitrary code.
While this heap overflow vulnerability could not be used by itself to obtain
root access on a rsync server, it could be used in combination with the
recently announced brk vulnerability in the Linux kernel to produce a full
remote compromise.
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.
Please note that this vulnerability only affects the use of rsync as a "rsync
server". To see if you are running a rsync server you should use the netstat
command to see if you are listening on TCP port 873. If you are not listening
on TCP port 873 then you are not running a rsync server.
New rsync release
In response we have released a new version of rsync, version 2.5.7. This is
based on the current stable 2.5.6 release with only the changes necessary to
prevent this heap overflow vulnerability. There are no new features in this
release.
We recommend that anyone running a rsync server take the following steps:
Update to rsync version 2.5.7 immediately.
If you are running a Linux kernel prior to version 2.4.23 then you should
upgrade your kernel immediately. Note that some distribution vendors may have
patched versions of the 2.4.x series kernel that fix the brk vulnerability in
versions before 2.4.23. Check with your vendor security site to ensure that
you are not vulnerable to the brk problem.
Review your
"use chroot = no" then remove that line or change it to "use chroot = yes".
If you find that you need that option for your rsync service then you should
disable your rsync service until you have discussed a workaround with the
rsync maintainers on the rsync mailing list. The disabling of the chroot
option should not be needed for any normal rsync server.
The patches and full source for rsync version 2.5.7 are available from http://
rsync.samba.org/ and mirror sites. We expect that vendors will produce
updated packages for their distributions shortly.
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
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0962 to this issue.
Regards,
The rsync team
I just took them from linux kernel mailing lists..
sure they could be wrong, but you'd think the real author would notice someone posting technical messages in his name....