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.
...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.
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/
i do it the slack way.
Also, patch every box which you root thanks to linux and rsync security problems.
Of course, to patch this, you should go to your local mirror, which will be down until they patch the rsync vulnerablity...
Doh!
Instructions on how to update Slackware to the latest and greatest rsync are at:a re-security&y=2003&m=slackware-security.399741
http://slackware.com/security/viewer.php?l=slackw
Of course if you're running a server you should theoretically be subscribing to the security mailing list. Right?
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
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.
This calls for Standard Slashdot Response #4:
Yay! This was so fast. Even when we suck we don't suck!
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.
You might want to take a look at Easy Automated Snapshot-Style Backups with Linux and Rsync posted by Mike Rubel. I think this is mentioned in the book Linux Server Hacks by O'Reilly (hack #42), although I don't have the book so I'm not sure.
Basically it uses rsync and cp to create a backup, but only changed files are actually copied; unchanged files are simply linked to. This saves a lot of disk space, and allows you to keep many backups on the system at one time, assuming most of your files don't change.
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!
(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.
I would say there are still uses for rsync server protocol. Setting up an account for secure, anonymous SSH access to rsync sounds like a nightmare to me.
Well now... let me be the first, then! Having a real user account for FTP access is, in certain environments, a security risk.
Of course, if you're still using FTP for non-anonymous access instead of SCP/SFTP, I'd guess that security isn't one of your priorities.
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