** For all versions of rsync prior to 2.6.3, see the August 2004 security advisory! ** If you're using a version prior to 2.6.1, see the April 2004 security advisory! ** If you're using a version prior to 2.5.7, see the December 2003 security advisory! **
February 28nd, 2005
Rsync version 2.6.4pre2 has been released. This release combines several new features with some improved delete efficiency and the usual array of bug fixes. Please try it out and send feedback to the mailing list!
See the release NEWS for the details of what changed since 2.6.3.
The changes since 2.6.4pre1 are as follows:
To build it from source, snag one of these: rsync-2.6.4pre2.tar.gz (signature), rsync-2.6.4pre1-2.6.4pre2.diffs.gz (signature). rsync-2.6.3-2.6.4pre1.diffs.gz (signature). Note that the diffs do not contain updates for the "patches" dir -- grab the tar file if you want the full release.
September 30th, 2004
Rsync version 2.6.3 has been released. It contains several new features and quite a few bug fixes.
See the release NEWS for the details of what changed since 2.6.2.
See the download page for all the ways to grab the new version, or snag one of these: rsync-2.6.3.tar.gz (signature), rsync-2.6.2-2.6.3.diffs.gz (signature).
August 12th, 2004
There is a path-sanitizing bug that affects daemon mode in all modern rsync versions through version 2.6.2, but only if chroot is disabled. It does NOT affect the normal send/receive filenames that specify what files should be transferred (this is because these names happen to get sanitized twice, and thus the second call removes any lingering leading slash(es) that the first call left behind). It does affect certain option paths that cause auxilliary files to be read or written.
The best fix is to apply this one-word patch to the sanitize_path() function in util.c:
--- orig/util.c 2004-04-27 12:59:37 -0700 +++ util.c 2004-08-11 23:37:27 -0700 @@ -743,7 +743,7 @@ allowdotdot = 1; } else { p += 2; - if (*p == '/') + while (*p == '/') p++; if (sanp != start) { /* back up sanp one level */
This bug-fix was released in version 2.6.3 of rsync.
One potential fix that doesn't require recompiling rsync is to set "use chroot = true" for all the modules in the rsyncd.conf file.
April 30th, 2004
Rsync version 2.6.2 has been released. It is a bugfix release that mainly fixes a bug with the --relative option (-R) in 2.6.1 that could cause files to be transferred incorrectly. This only affected a source right at the root of the filesystem, such as "/" or "/*" (if you first "cd /" and then copy from ".", it would not tickle the bug).
See the release NEWS for the details of what else was fixed.
April 26th, 2004
Rsync version 2.6.1 has been released. It is primarily a performance release that requires less memory to run, makes fewer write calls to the socket (lowering the system CPU time), does less string copying (lowering the user CPU time), and also reduces the amount of data that is transmitted over the wire. There have also been quite a few bug fixes. See the release NEWS for the full details.
April 26th, 2004
There is a security problem in all versions prior to 2.6.1 that affects only people running a read/write daemon WITHOUT using chroot. If the user privs that such an rsync daemon is using is anything above "nobody", you are at risk of someone crafting an attack that could write a file outside of the module's "path" setting (where all its files should be stored). Please either enable chroot or upgrade to 2.6.1. People not running a daemon, running a read-only daemon, or running a chrooted daemon are totally unaffected.
The problem with rsync hanging at the end of the transfer on Cygwin had been previously traced to a signal-handling bug in their compatibility DLL. This bug appears to now be fixed in DLL version 1.5.7-1, and Cygwin users are reporting that upgrading the DLL removes the hang-at-end-of-transfer problem for their existing rsync executable. (Note that this doesn't solve a hang that some folks see in the middle of a transfer -- using daemon mode instead of ssh can work around that one.)
January 1st, 2004
Two important things to note in the new release:
One other item of note is that the oft-requested option "--files-from" is now available. This option lets you specify a list of files to transfer, and can be much more efficient than a recursive descent using include/exclude statements (if you know in advance what files you want to transfer). The list of files can come from either side of the connection, so it is possible for a server to provide the file-list that lets someone grab a server-specified set of files, for example. See the rsync man page for more details.
For a full list of changes in version 2.6.0, see the release NEWS.
December 4th, 2003
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:
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.
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:
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.
The rsync team would like to thank the following individuals for their assistance in investigating this vulnerability and producing this response:
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0962 to this issue.
Regards,
The rsync team