If you're using a version of rsync from 2.6.9 to 3.0.1 that has extended attribute (xattr) support enabled, you should upgrade to 3.0.2 to avoid a potential buffer overflow problem. All 3.x versions have the potential to support xattrs (depending on OS availability and the configure options used), but version 2.6.9 had to be patched for this support. You can run the command "rsync --version" and look for the string "xattrs" (as long as it is not "no xattrs") to see if your rsync is affected.
For those running affected versions, there is a patch with the fix available.
Those running a writable rsync daemon can opt to refuse the "xattrs" option as a way to avoid the problem without an upgrade:
refuse options = xattrs
(If you already refuse options, be sure to append "xattrs" to your existing config parameter rather than adding another refuse directive.)
Three security advisories affect people who run a writable rsync daemon: The first affects only those with "use chroot = no" (which is not a very safe combination in general), the second affects a daemon that has daemon-excluded files that are being hidden in a module's hierarchy, and the third affects only those with "use chroot = yes". Included are simple config-change suggestions that should help you to avoid the security issues and patches that make things safer. These advisories affect all rsync versions.
If you are running a writable rsync daemon with "use chroot = no", there is at least one way for someone to trick rsync into creating a symlink that points outside of the module's hierarchy.
This means that if you are allowing access from users who you don't trust, that you should either figure out a way to turn on "use chroot", or configure the daemon to refuse the "links" option (see "refuse options" in the rsyncd.conf manpage) which will disable the ability of the rsync module to receive symlinks. After doing so, you should also check that any existing symlinks in the daemon hierarchy are safe.
Starting with the 3.0.0-pre6 release, there is a new daemon parameter available: "munge symlinks". This allows an rsync daemon to accept symlinks and return them intact (with even a leading slash still there, which is new for a non-chroot daemon), but will not allow the symlinks to be used while they are in the daemon's hierarchy.
For those running 2.6.9, there is a patch for 2.6.9 to implement this parameter.
Any admin applying that patch should read the "munge symlinks" section of the modified rsyncd.conf manpage for more information. You can also read about this parameter in the rsyncd.conf manpage from a 3.x version.
If you are running a writable rsync daemon that is using one of the "exclude", "exclude from", or "filter" parameters in the rsyncd.conf file to hide data from your users, you should be aware that there are tricks that a user can play with symlinks and/or certain options that can allow a user that knows the name of a hidden file to access it or overwrite it (if file permissions allow that).
You can avoid the symlink problem using the suggestions in the advisory above.
When a daemon has "use chroot = no" set , there was some buggy
exclude-checking for these options:
--files-from. These are fixed in the 3.0.0pre7 release. For
those running 2.6.9, there is a patch for
2.6.9 to fix these checks.
Some of the above options can still cause problems if an excluded
sub-directory or filename is inside the option's directory hierarchy and the
names of a transferred file clashes with it. The affected options are the
--*-dest options (of which only
is particularly worrisome),
You can avoid these sub-path problems by putting the following "refuse options" setting into your rsyncd.conf file:
refuse options = link-dest backup-dir partial-dir
Those who aren't using an rsync with the latest exclude fixes may want to add some of the other affected options as well.
If you are running a writable rsync daemon with "use chroot = yes", you should take care that users cannot upload their own library files and attempt to load them.
Beginning with rsync 3.0.0pre10, you can specify an inside-chroot path that makes the top of the transfer a subdirectory inside the chroot area, and that automatically makes library loading occur outside the transfer area (assuming you didn't pick an unwise subdirectory name for the transfer area and you don't have symlinks that point outside the transfer area).
If that solution is not good for you, the easiest way to protect your daemon is to create some appropriate directories in the top of your module's path hierarchy, such as "/etc", "/lib", and "/usr" (and any other top-level dirs that might be in the load path), chown those directories to some other user than the one that the module runs as (so that rsync will not be able to write files there, assuming that it is not run as root), and then hide the dirs using an exclude directive (either add a new one or extend your existing one):
exclude = /etc /lib /usr
Doing all that will assure you that no user will be able to use rsync to upload a library that can be potentially loaded while rsync is attempting to perform an action, such as translating a username. You can feel free to put trusted libraries that you want rsync to access in the protected hierarchies, as desired.
Also available in rsync 3.0.0pre10 is a new daemon parameter that allows you to avoid the accessing of user/group-name translation libraries by a chrooted rsync: the "numeric ids" daemon parameter lets you turn on a forced numeric-only mode. The default for a chroot module is to enable this parameter, while the default for a non-chroot module is to disable it.
For those running 2.6.9, there is a patch for 2.6.9 to add the "numeric ids" daemon config parameter. (The patch will only apply cleanly if you've already applied the munge-symlinks diff mentioned above.)
If you're using a version of rsync prior to 2.6.8 that was patched to include extended attribute (xattr) support, you should upgrade to 2.6.8 or later to avoid a potential buffer overflow problem.
If you're using a version of rsync prior to 2.6.6, there is a potential null-pointer security bug in the zlib code. You can avoid its affect in an rsync daemon situation by configuring rsync to refuse the "compress" option.
There is a path-sanitizing bug that affects daemon-mode in rsync versions prior to 2.6.3, but only if "use 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 auxiliary files to be read or written.
One potential fix that doesn't require recompiling rsync is to set "use chroot = true" for all the modules in the rsyncd.conf file.
There is a security problem in all versions prior to 2.6.1 that affects only people running a read/write daemon with "use chroot" disabled. If the user privs of a module in the daemon config 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.
Rsync versions prior to 2.5.7 contain a heap overflow vulnerability that
could be used to remotely run arbitrary code, but this only affects the use of
rsync as an "rsync daemon" (where rsync handles incoming socket connections,
typically on port 873).